[RFC] Why FreeBSD ports should have branches by OS version

Julian Elischer julian at freebsd.org
Fri Jun 23 04:28:20 UTC 2017


On 23/6/17 7:28 am, Grzegorz Junka wrote:
>
> On 22/06/2017 15:50, scratch65535 at att.net wrote:
>> [Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
>> <matthew at FreeBSD.org> wrote:
>>
>>> On 2017/06/22 15:03, scratch65535 at att.net wrote:
>>>> Why don't the same choices apply here?  What am I missing?
>>> Two things:
>>>
>>>   1) It's progress in the development of the FreeBSD base system that
>>> drives the release cycle.  The general state of the ports does not 
>>> exert
>>> much influence on release frequency -- nor should it.
>> Still not getting it, I'm afraid.    How often does the base
>> system undergo such drastic architecture changes that existing
>> ports won't run under it?  I haven't really been monitoring the
>> situation, but I'd guess it's very seldom if only because such an
>> architectural change is a cursëd big job that can hardly ever be
>> justfied.
>>
>> I'd guess that most adults for whom systems are tools not toys
>> are not too dissimilar to me:  I want to *use* my tools, not
>> spend time replacing them every quarter or even every year.  As
>> long as they do the job and don't compromise the system, they're
>> fine by me.  I have apps running under Win7 that were written for
>> W2K (and in one case NT, iirc), and they're just as useful today
>> as they were then.  They do the job: why in the name of sanity
>> should I replace them?
>>
>
> Not sure how you use your tools or in which industry you work. Take 
> front-end development for example.

here lies the crux of the problem.
FreeBSD is often not a front-end software module.
It is often used to provision off-line (from a 
management/administrative perspective) systems.
Front end or personal systems can be upgraded day by day.
Real products such as routers, proxies, gateways, accounting systems, 
firewalls etc. can NOT be upgraded every day.
you are lucky if the customer allows you to do it once a year.

> Chrome is releasing a new version every couple of days. Sure, I 
> don't upgrade every release, but when I am developing a website, I 
> want to test using the same version that my customers are using, 
> which is the latest, since Chrome on Windows updates itself 
> automatically. The same with new versions of Firefox. Often new 
> versions of browsers require new versions of libraries to support 
> new features (CSS/JavaScript). That requires new versions of 
> compiler and transpilers. They may, in turn, require an updated 
> version of node or npm.
>
> Take server-side development as another example. Erlang is releasing 
> a new version of OTP every couple of weeks. Sure, I don't need a new 
> version when supporting an old application, but I may need one when 
> starting a new application. Especially that many libraries that I am 
> going to use won't support Erlang older than a specific version.
>
> A similar story with C++ development, where the standard is being 
> constantly developed and compilers are adding these features every 
> release. Again, you may not need these new features, but a library 
> that you need to use may require the new version.
>
>  No matter how long you are going to maintain a specific version of 
> ports with locked down versions of applications, there will surely 
> come a time when you will need to upgrade. And for every user that 
> time will be different. The current model is in my opinion the most 
> common denominator - we can't maintain multiple branches with past 
> versions so lets try to properly maintain one with current versions.
>
> Grzegorz
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to 
> "freebsd-ports-unsubscribe at freebsd.org"
>
>



More information about the freebsd-ports mailing list