Upcoming Releases Schedule...

[Robert Watson]

On Wed, 17 Sep 2008, Jo Rhett wrote:

>> On Mon, 15 Sep 2008, Jo Rhett wrote:
>>> Robert, I'd like to point out to you that when I complained about 6.2's 
>>> accelerated EoL, I was soundly boxed around the ears and told that I 
>>> should have been paying attention to the projected EoL date when we 
>>> decided to roll out 6.2 across the business.
>>> 
>>> Now you are saying that expected EoL will be determined at some random 
>>> point in the future based on gut feelings about how well a completely 
>>> different branch is doing.
>>> 
>>> How can I reconcile these disparate points of view?  How does one focus on 
>>> testing and upgrade cycle for an "appropriately supported release" when 
>>> the decision for the support cycle is completely up in the air?
>> 
> On Sep 16, 2008, at 12:47 PM, Robert Watson wrote:
>> The FreeBSD Project, as with any other company or organization, responds to 
>> events as they occur.  We try to plan ahead, and when things go better or 
>> worse than expected, we sometimes change the plans.  As far as I know we've 
>> never *shortened* the expected support timeline for any branch or release, 
>> but we have on occasion lenthened them when we feel it's important to do 
>> so.  I'm not sure what other answer is possible.
>
> No other answer.  But nobody has yet provided what the EoL period is going 
> to be.  I have no problems with a period being extended ;-)  But the 
> business needs to know the minimum EoL for a given release to determine if 
> upgrading to that release is viable.

Well, a starting answer is the policy found on http://security.FreeBSD.org/:

Early adopter
   Releases which are published from the -CURRENT branch will be supported by
   the Security Officer for a minimum of 6 months after the release.

Normal
   Releases which are published from a -STABLE branch will be supported by the
   Security Officer for a minimum of 12 months after the release.

Extended
   Selected releases will be supported by the Security Officer for a minimum of
   24 months after the release.

At the time of release, we know if a release is considered "early adopter", 
and attempt to clearly mark it as such.  The harder question is whether or not 
we will start out considering a release "normal" or "extended" -- sometimes we 
are able to make that decision at the time of the release (i.e., we believe 
firmly it's the last release on the branch at the time of release), but on the 
whole we will make that decision based on the facts on the ground.

An important factor is whether or not we consider the release a highly 
maintainable release, and while we have intuitions at the time of release, 
that's something we can only learn in the first couple of months after it's in 
production.  I don't know of any COTS software house that really does it any 
differently, and I'm not sure you could do it differently -- no one plans to 
ship a lemon, but once in a while you discover that things don't go as 
planned.

Robert N M Watson
Computer Laboratory
University of Cambridge