Changes to the FreeBSD Support Model

Juanitou

Well-Known Member

Thanks: 124
Messages: 453

#1
For your information:
Changes to the FreeBSD Support Model
-----------------------------------------------------------------------

Over the past several months, the teams responsible for supporting the
FreeBSD operating system discussed the current support model, and how
that model can be improved to provide better support for FreeBSD users
and consumers.

The changes below greatly improve FreeBSD support, reduce turnaround time
for Errata Notices and Security Advisories, provide consistency between
binary package sets and the underlying FreeBSD base system version, and
reduce the amount of time before new features are included in the official
FreeBSD binary package sets.


Changes Proposed in a New FreeBSD Support Model
-----------------------------------------------------------------------

The proposed changes include:

- Moving from a point release-based support model to a set of releases
from a branch with a guaranteed support lifetime.

- Resolving our arbitrary (and unofficial) 5-year branch lifetime
guarantee. The support policy is that the stable/X branch will be
supported for 5 years (minimum) from the point X.0-RELEASE is released.
We now guarantee a 5-year lifetime on the branch, regardless of how many
releases are built from the branch. Additionally, a "last minute"
release from the stable/X branch does not constitute expanding the support
lifetime for the branch as a whole for an additional two years.

- The Security Officer or Ports Management Team may extend support for any
individual numbered release or branch at their discretion, in
exceptional cases.

- A new stable/ branch release will not occur before two years after the
X.0-RELEASE from the prior branch. This limits the number of
simultaneous supported branches, which will greatly reduce the overall
number of branches that must be maintained and build-tested for
Security Advisories and Errata Notices, reducing turnaround time.

- Each new release from the stable/X branch deprecates the previous
release on the branch, providing a three-month window within which
consumers are urged to upgrade to the latest release. During this
three-month window, Security Advisories and Errata Notices will still
be issued for the previous release, as necessary.


How These Changes Benefit FreeBSD Consumers
-----------------------------------------------------------------------

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.


When The New FreeBSD Support Policy Will Become Effective
-----------------------------------------------------------------------

These changes are planned to become effective with FreeBSD 11.0-RELEASE,
which is still a number of months away.

FreeBSD releases from earlier branches will continue to be supported in
accordance with the policy that was in effect at the time they were
released.


Deficiencies in the Current FreeBSD Support Model
-----------------------------------------------------------------------

- The FreeBSD support model is release-based, versus branch-based.
Specifically, we determine if a FreeBSD release will be a normal- or an
extended-support release in the final phases of the release cycle, while
in reality we have no way to determine how successful the release is
until weeks or months later.

- We do not clearly define how long the stable/X branch will be supported
after its creation. Since FreeBSD 5.x, we have historically supported a
stable/X branch for a minimum of five years after the X.0-RELEASE is
available. The length of time is not a defined policy, which can make
it difficult to decide which branch to track.

- The current support model prevents building third-party binary packages
for the most recent release from a stable/ branch because we must
provide packages that can be run on the oldest supported release from
the branch.

- 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.

- The support model can overlap in non-intuitive ways, making it difficult
to decide when evaluating FreeBSD features versus support timeframe from
any given branch. When changes to the support model were initially
being discussed, the FreeBSD supported releases were:
- 8.4-RELEASE: June 30, 2015
- 9.1-RELEASE: December 31, 2014
- 9.2-RELEASE: September 30, 2014

(Note that in this case support for the newer 9.2 release ends before
support for FreeBSD 9.1.)

- A new release from a branch automatically extends the support lifetime
by two years, minimum. If X.Y-RELEASE was initially planned to be the
final release from the stable/X branch, it is an extended-support
release by definition. If it is necessary to follow X.Y-RELEASE with
X.Z-RELEASE for any reason, we would have two concurrent
extended-support releases from the same branch in sequence. This has a
serious impact on the quality of an update when there are multiple
supported releases on a branch. The problem becomes worse when the
oldest supported release on the branch has a longer support lifetime
than the newest release on the branch.


Key Items Considered in Changes to the FreeBSD Support Model
-----------------------------------------------------------------------

Some of the things that should be included in a new FreeBSD support
model include:

- Guaranteeing, and explicitly stating, the support lifetime of the
stable/X branch as a whole, versus independently determining the
support lifetime of the individual releases from the stable/X branch.
- Providing package sets that are compatible with the latest release from
the branch, ensuring that new features introduced into the FreeBSD base
system can be enabled by default in binary package builds.
- Security Advisories and Errata Notices should be more aligned between
src/ and ports/. There is an endless list of edge cases with this
particular point, but consider a situation where a critical security
vulnerability is discovered, and the underlying code has changed between
X.Y-RELEASE and X.Z-RELEASE. In addition to the possibility of
regression in one (or both) of the supported releases due to subtle
changes in the security fix, it introduces potential delay in providing
the security fix as the number of supported releases increases. Each
supported release adds to the amount of time it takes for:

- 1) patching the vulnerability,
- 2) testing the patch,
- 3) verifying the patch is correct, and
- 4) building the freebsd-update(8) binary update bits.

If a problem is discovered at any time during step (4), procedure resets
to step (1). (It should be stressed that this is not due to lack of
hardware, but the order in which the various steps of issuing Security
Advisories and Errata Notices must occur.)

- Providing a support model that is easier more predictable and easier to
follow.

--
Matthew Seaman Core Team Secretary
matthew at FreeBSD.org core-secretary at FreeBSD.org
Link: https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html
 

kpa

Beastie's Twin

Thanks: 1,706
Messages: 6,125

#2
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

Well-Known Member

Thanks: 71
Messages: 297

#3
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.
 

pathiaki

Member

Thanks: 2
Messages: 69

#5
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

Daemon

Thanks: 457
Messages: 2,099

#6
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

Active Member

Thanks: 15
Messages: 114

#7
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

New Member


Messages: 1

#8
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 .
why you think so?
 

poorandunlucky

Well-Known Member

Thanks: 26
Messages: 359

#9
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.
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

Son of Beastie

Thanks: 1,389
Messages: 2,964

#10
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

Administrator
Staff member
Administrator
Moderator

Thanks: 6,237
Messages: 27,228

#11
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

Son of Beastie

Thanks: 1,389
Messages: 2,964

#12

alx82

Member

Thanks: 17
Messages: 26

#13
- 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

Administrator
Staff member
Administrator
Moderator

Thanks: 6,237
Messages: 27,228

#14
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

Member

Thanks: 17
Messages: 26

#15
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

Administrator
Staff member
Administrator
Moderator

Thanks: 6,237
Messages: 27,228

#16
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.

Code:
.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
 
Top