Upcoming Releases Schedule...

netgeek netgeek at bgp4.net
Sun Sep 21 01:02:28 UTC 2008


Robert Watson wrote:
> When it comes to commercial OS products, like Windows and Mac OS X, 
> there is often a strict requirement to live on the most recent minor 
> release in order to continue to receive support.  For example, you won't 
> make a lot of headway turning up at Apple and demanding security updates 
> for Mac OS X 10.5.0 a year after it has been released.  The answer will 
> be "Great, update 10.5.3" (or something along those lines) -- not only 
> will it fix the security issues, but it will support the hardware we now 
> sell.  In that sense, we're actually quite different: rather than saying 
> "Sorry, 6.2 is vulnerable, please upgrade to 6.3", we say "You can live 
> on 6.2 for up to 18 months and receive *only* security and critical 
> errata patches".
> 
> Don't get me wrong: I would love to see us support all releases for 24 
> months (or even more) after they ship.  I think our users would 
> appreciate that also. 

Perhaps there is a middle ground here?  What about a statement that each 
major branch (6.x, 7.x) will be supported for at least 24+ months from 
its last production release?  Smaller periods of support could be given 
to minor releases along the way (7.2, for example), but at least 
companies would know that if they installed a 6.x version, they'd have 
support for a couple of years, even if that might mean upgrading to a 
newer minor version if there was a problem.

I really wouldn't mind being told to upgrade from 7.2 to 7.4_p12 because 
its been 20 months since the last 7.x release. Because companies are 
used to the Apple and Microsoft way you outlined above, I don't think 
they'd have a huge problem with it either.  Wouldn't it make it easier 
on the teams to only ofter extended support for the major versions, 
rather than trying to support specific minor versions (6.3, 6.4, 7.0, 
7.1) for an extended time?

I'll admit, in the early days of 5.x, I really didn't like having to 
jump between minor versions.  Let's face it, things didn't really settle 
down until, what, 5.3?  In those days, being able to stay on a specific 
minor release was a Good Thing.  However, I don't have the same kind of 
API and upgrade fear going from 6.x to 6.y.

Maybe there are people out there who truly fear upgrading from 6.3 to 
6.4, and need both supported for an extended time.  But if resources are 
limited, it seems that only offering extended support for the latest 
release from a major branch would be the way to go.  Perhaps 6-12 months 
for a minor release, 24+ months for the entire major release train?

I'm not demanding anything, or saying this is the right way.  I'm just 
wondering if there is a compromise out there that would give companies 
the security that their 6.x or 7.x server will have 2 years+ of support 
for vulnerabilities, while at the same time not requiring the developers 
to extended support for multiple minor releases.

I'll now go put on my asbestos undergarments and sit in the corner. ;-)


More information about the freebsd-stable mailing list