# Changes to the FreeBSD Support Model



## Juanitou (Feb 4, 2015)

For your information:


> Changes to the FreeBSD Support Model
> -----------------------------------------------------------------------
> 
> Over the past several months, the teams responsible for supporting the
> ...



Link: https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html


----------



## kpa (Feb 6, 2015)

Definitely a step towards the right direction. What we've had so far with overlapping support periods has been very confusing for newcomers and has created unnecessary work for developers who've had to backport the same fixes to multiple different minor versions of the same major branch which is a total waste of time and effort.


----------



## NewGuy (Feb 8, 2015)

kpa said:


> Definitely a step towards the right direction. What we've had so far with overlapping support periods has been very confusing for newcomers and has created unnecessary work for developers who've had to backport the same fixes to multiple different minor versions of the same major branch which is a total waste of time and effort.



Agreed. In the past I could install the latest version of FreeBSD only to have support dropped a few months later. Meanwhile releases from a branch that is a few years old continues to get support. That was a bit confusing and frustrating, especially if newer features were desired. Now I think the new model will make it easy to get new features and support at the same time. Plus this makes planning upgrade cycles easier.


----------



## gkontos (Feb 8, 2015)

Also, the new package manager in combination with freebsd-update(8), has made it a lot easier now to maintain and upgrade a server.


----------



## pathiaki (Feb 12, 2015)

Although I agree almost in total with this, something of a 'standard number' of point releases should be embraced as well.  Given that we can move forward at greater speed, a back port of new features consumes some amount of time.  Also, the release process should give some indication of 'progress with a definitive end'.

Too many people lag behind and don't perform proper system administration.  Machines require updates and maintenance and it should be performed on a regular basis.  

Granted, patches for security fixes MUST be made available for the supported versions.  However, new features being backported, if such a thing is occurring, should be abandoned.  If someone is using a near EOL version and wants feature 'X' because it's in the next version release, they should have to upgrade.  This will lead to a lot less problems updating the machines due to the 'unknown' factor of someone who previously support the system with a non-published patch.

I believe that the Project has something in place already in the way this is being handled.  However, I would like to see it become more stringent.  Using the 'last' 'present' 'new' method is probably best and limiting it to 3 point releases.  This would lead to a cycle like this:

7.2
8.1
9.0
7.3 <- done
8.2
9.1
10.0
8.3 <- done
9.2
10.1
11.0
9.3 <- done
10.2
11.1
12.0

Of course, it could be limited to 2 point releases as well.

This would probably cut down on a lot of mail about what is the next release and what date it is expected to happen.  If the cycle was cut to 2 point releases, then, that fits the model of 3 releases a year.  There would be a .2 .1 .0 point release of the individual versions in a year.  The version would be done at x.2 .


----------



## gkontos (Feb 12, 2015)

Although I have always tried to keep up with the new releases, I find myself lately sticking with 9.4 (when released) on at least 2 servers. Why? because migrating to 10.X will cost a lot of down time.


----------



## MMacD (Sep 1, 2015)

There's a lot to be said for what might be called "the Volkswagen release scheme".  Back in the Käferchen's day, reliability was emphasised, cosmetic changes generally being few and often hard to even detect (it used to be quite a game, determining what some VW's model year was).  They originally had a badge program for achieving a certain kilometrage, e.g. 100K KM, but they had to quit because too many people were collecting too many of them, so it was no longer a distinction.

Speaking for myself at least, I'd far rather  have a new major release only every, say, 3 years or even 5, with yearly point releases in between and most of the effort being put into reliability and human-factors improvements, support commitment being fixed at 2 major releases (e.g., support for v10.* would lapse on release of v12.0).  That would provide a lot of stability.  Servers need stability more than innovation.

Of course, a packaging program would be nice, too, particularly if anyone wants FreeBSD to survive the threat from Linux.  I don't think I'm telling tales out of school when I point out that at least some vendor tech-support people refer to FreeBSD as "an unpopular operating system", as though it's a mistake to use it.  The number of webhosting sites offering FreeBSD as an option is quite small, as far as I can tell, and getting smaller.  It might actually have gone to zero by now, because I've not checked in awhile.

Most people don't want to have to build their own tools.  Nobody sells a hammer kit, or a kit for making one's own saw, light bulbs, or lathes.  Anyone who wants a hammer, saw, light bulb, or lathe wants it for some reason other than to pass the time.  They want to be able to _use_ it for solving a _bigger_ problem, a problem that's important to them.  

Right now, FreeBSD is a tool _kit_.  One can make a server, or a desktop, or a firewall, or....  But the take-home concept is _can make_.  If we want FreeBSD to avoid becoming another Minix or UCSD P-System, the folks in charge need to devote resources to packaging it in a few of the more important configs, server being favorite.  I used to work on the UCSD system -- it was very nice!  I still have a copy of the source.  But it's now a curiosity, totally obsolete.  The world has moved on.  FreeBSD is being left behind too, even though it's better than Linux.  But Betamax was better than VHS, too, and we all know what happened with that:  utility trumps technical goodness every time.


----------



## meriane (Mar 28, 2017)

pathiaki said:


> Although I agree almost in total with this, something of a 'standard number' of point releases should be embraced as well.  Given that we can move forward at greater speed, a back port of new features consumes some amount of time.  Also, the release process should give some indication of 'progress with a definitive end'.
> 
> Too many people lag behind and don't perform proper system administration.  Machines require updates and maintenance and it should be performed on a regular basis.
> 
> ...


why you think so?


----------



## poorandunlucky (Nov 5, 2017)

MMacD said:


> There's a lot to be said for what might be called "the Volkswagen release scheme".  Back in the Käferchen's day, reliability was emphasised, cosmetic changes generally being few and often hard to even detect (it used to be quite a game, determining what some VW's model year was).  They originally had a badge program for achieving a certain kilometrage, e.g. 100K KM, but they had to quit because too many people were collecting too many of them, so it was no longer a distinction.
> 
> Speaking for myself at least, I'd far rather  have a new major release only every, say, 3 years or even 5, with yearly point releases in between and most of the effort being put into reliability and human-factors improvements, support commitment being fixed at 2 major releases (e.g., support for v10.* would lapse on release of v12.0).  That would provide a lot of stability.  Servers need stability more than innovation.
> 
> ...



That's what I see FreeBSD as, instead of "The power to serve." (probably to try and get funding from big companies), their slogan should be "Make your goddamn OS." and that's why I like it...  It doesn't set any promises it fails to meet, and that's more important than half-meeting, or failing to meet promises.  No blame is better than blame, period.

Also, the slogan "The power to serve." isn't very good, because at the end, it's an individual who's going to make the choice to use FreeBSD, and no individual wants to serve... especially not in Hell (Beastie); also, current trends have shifted to microfinancing, where most companies feel it's better, or easier to try to get $1 from 100 people than $100 from one person...  Maybe if FreeBSD tried to please the 99 instead of "the 1%", it would do better with money, and would be able to push much more complex and complete things, and would also have more support (more users) at large, and that would probably mean more contributors, and it would be an efficient to try to keep more contributors towards the demand for contribution.

As for support, FreeBSD is free...  I never expected it to have any, but then, I'm not an entitled American (sry, but I just had to say it, and I just can't find a better image to express my point), and maybe the foundation feel entitled people have more money because they think their behavior reflects such, but that's not true...  I think those people are sad, they make me sad, and before you got used to it, they made you sad, too...  They shouldn't be respected, they should be put back in their place.

FreeBSD should put its implicit values on confidential paper, and try to continue what it's doing, and be honest about its objectives.  Why do we hate Linux?  Because we need programmers; we don't actually hate Linux.  What can we do to meet our means with our ends?  (oO)  ...

I like FreeBSD because it teaches me...  it's a constant test...  its test is that it must make sure that I love it, and respect it, and understand it.  As something that is so close to me every second of every day, I want it to want me to love it.  My computer serves _me_, it's a machine, it should obey *my* commands.  I should be able to do whatever I want with and to it without any kind of difficulty or impairment.  I should own it.  I should be able to reach into it, and rip its heart out, or give it new eyes, and it should never flinch, and it should never put its arms in the way, or tell me I can't do that.  I should be able to see right through it, I should know it, *I* should own it.  And I can't do that with Windows, or even Android.  People who I quite likely would spit in their faces and walk away from them if I ever met them control my computer, I don't.  They blind me from it, they blind me from what I know as reality; my reality.  They're a glass, sometimes rose-tinted, between me and my/the world.  I don't want that.  I don't want anything between me and the world, and you have to see it from my perspective - the world isn't a place where there are no computers; that's not what I'm saying.  There always were (and obviously/quite likely always will be) computers everywhere in my world, I don't mean that I want to go play outside here, or live without looking at my phone... it's part of my reality, it's part of my world.  Hell, if I could plug it into my brain: I would; but I would much rather if what was at the other end of the cable was FreeBSD, not Windows, not Google, not anything like that... that's not free.  I want to live in a free world.  ( : FreeBSD).

k.  'nuf.

Have fun with that.  : >


----------



## ShelLuser (Feb 16, 2018)

I know I'm responding to an old thread, but the whole thing is still pretty much relevant today.

The only gripe I have with the new system is that it has actually become harder, not easier, to plan for an upgrade. Previously with the 9 and 10 branches there was a set date at which point the support would end. This allowed you to carefully plan for the next required upgrade.

But as it is now we no longer have this information to work with. If you check the supported releases you will see this for yourselves. 11.1 will be supported until 3 months after the release of 11.2, but when this happens is a mystery.

My server currently runs 10.3 and I have planned the upgrade for a while now. However... for all I know I could be performing an upgrade (this or next month) after which the next release could come out. Effectively resulting in another required upgrade shortly after the previous one, but this time with much less room for planning because you'll only have a 3 month time frame.

I can definitely understand that this makes things easier on the developers, and I'm all in favor for that, but I don't necessarily agree with the statement that this benefits me as a consumer. I mean (from the official announcement):



> These changes to the FreeBSD support policy will reduce turnaround time
> for security advisories and errata notices, provide binary package sets
> that are more closely aligned with the latest FreeBSD release from a given
> branch, and clearly define the minimum length of time that a branch will
> receive support.


Each to their own but "11.2-RELEASE + 3 months" isn't very clear to me because that basically tells me nothing substantial since I have no idea when 11.2 is about to be released. In the old situation you had a clear date to work with, which allowed for careful preparations.

Even though the upgrade process is usually pretty painless I also think it's important to realize that in certain environments it's still not something one can do on a whim. In which case 3 months isn't as much time as it might seem. Especially if you keep in mind that this includes both the planning process as well as the implementation process.

Of course I realize that new versions aren't carelessly released and that we probably don't have to worry about a new release appearing every 2 months, but even so.. it is a concern. Because although unlikely there's nothing stating otherwise either.

Just my 2 cents and observations here.


----------



## SirDice (Feb 16, 2018)

ShelLuser said:


> But as it is now we no longer have this information to work with. If you check the supported releases you will see this for yourselves. 11.1 will be supported until 3 months after the release of 11.2, but when this happens is a mystery.


Does this help?
https://www.freebsd.org/releases/11.2R/schedule.html

If I recall correctly there's supposed to be a release every six months. So in July 2018 we'll hopefully see 11.2, for Q1 2019 12.0-RELEASE is planned, then summer 2019 will probably be for 11.3, January 2020 12.1-RELEASE and so on.


----------



## ShelLuser (Feb 16, 2018)

SirDice said:


> Does this help?
> https://www.freebsd.org/releases/11.2R/schedule.html


That is definitely a step in the right direction! Thanks for that one, I glossed right over that tidbit.



SirDice said:


> If I recall correctly there's supposed to be a release every six months.


Hm, that reminds me a bit of the Ubuntu Linux release cycle  Still, it's definitely something one can work with, thanks for the heads up there.


----------



## alx82 (May 28, 2018)

Juanitou said:


> - Ports maintainers must support the oldest supported release on the
> branch within the Ports Collection. This adds significant complexity to
> the tree in general, but also prevents enabling new features by default.
> An example is the upgrade to WITH_NEW_XORG where these features depend
> on changes to the base system that are only available in X.Z-RELEASE.



I'm having difficulties in understanding how the above point influences the branches of the ports. For instance on Ports SVN Branches, I can see branches like 201xQx (for example 2018Q1), but how I'm supposed to know which FreeBSD release is that branch compatible with?


----------



## SirDice (May 28, 2018)

alx82 said:


> but how I'm supposed to know which FreeBSD release is that branch compatible with?


With FreeBSD there is no specific "release" ports branch as you would have with Ubuntu for example. All FreeBSD versions use the exact same ports tree. So all _supported_ FreeBSD versions will use the same ports tree (and by extension, the same quarterly branch).


----------



## alx82 (May 28, 2018)

SirDice said:


> With FreeBSD there is no specific "release" ports branch as you would have with Ubuntu for example. All FreeBSD versions use the exact same ports tree. So all _supported_ FreeBSD versions will use the same ports tree (and by extension, the same quarterly branch).



I was aware of that, but I was wondering how new support model influences the ports tree. For example, let's say that xorg version A works on FreeBSD A, but xorg version B uses features that are only available on FreeBSD version B. How this can be handled by a port? I would appreciate having a specific example of a port structure (Makefile, distinfo, etc...) in case it is possible to handle that.


----------



## SirDice (May 28, 2018)

alx82 said:


> For example, let's say that xorg version A works on FreeBSD A, but xorg version B uses features that are only available on FreeBSD version B. How this can be handled by a port?


It depends. Typically it's done using some logic in the port based on OSVERSION, graphics/drm-next-kmod is a good example of this.


```
.if ${OPSYS} == FreeBSD && ${OSVERSION} < 1101511
IGNORE=         not supported on 10.x or older, no kernel support
.endif
.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1200000 && ${OSVERSION} < 1200058
IGNORE=         not supported on older CURRENT, no kernel support
.endif
.if ${OPSYS} != FreeBSD
IGNORE=         not supported on anything but FreeBSD (missing linuxkpi functionality)
.endif
```


----------

