Upcoming Releases Schedule...
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