Upcoming Releases Schedule...

[Robert Watson]

On Fri, 5 Sep 2008, Ben Kaduk wrote:

> To quote from the same website:
> 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.
>
> I don't remember seeing any speculation about 6.4 being an extended release, 
> so, EoL is 12 months after release, whenever that actually happens.

Unfortunately, it's a little hard to tell at time-of-release whether a 
particular release will become extended life or not.  This is because extended 
support status is dependent on the success of the release (i.e., general 
perception of stability and performance), but also based on the success of 
other simultaneously releasing branches.

We normally don't make a .0 release "extended support" because there's a 
reasonable expectation that .0 releases will see more limited deployment than, 
say, a .1 or .2 release, and that those incrementally later releases will be 
significantly more stable or performant as a resut of the burn-in the .0 
received from earlier branch adopters.  How long we keep release 6.x releases 
will depend entirely on how successful 7.x is; I think there's a reasonable 
expectation that 6.4 or 6.5 will be the last 6.x release, in which case we 
would want to grant it extended support status.  But what happens depends a 
lot on how successful 7.1 is.  My hopes are high, but there's nothing like 
real-world deployment to shed light on things :-).

Robert N M Watson
Computer Laboratory
University of Cambridge
>
> I thought this was mentioned in the previous thread you started about EoL,
> but I didn't see it in a quick search.
>
>>> The answer to that is not clear -
>>> nor do I know if it should be clear yet.  I don't know when the type of
>>> support decision is made, but I suspect it's not this early in the
>>> process.
>>
>>
>> The release date for 6.4 is ~30 days away, isn't it?
>>
>> Also given that we've previously seen overlaps such that a newer version is
>> only supported to the same EoL as the older version, that would pretty much
>> dictate that spending resources on testing 6.4-REL and/or upgrading would be
>> futile.
>>
>
> That's the difference between a long-term-support branch and a regular branch;
> many OSes do that.  If you want to run the same machines for a long time and
> not have to do a huge battery of tests (at the expense of getting new features
> and better performance in the interim), you use long-term branches.
> The regular branches that get released later, will then become unsupported
> at the same time as the (older) long-term branch.
>
> Yes, it's poor when a long-term branch goes EoL before there's another one
> ready to take its place, but if the new one isn't ready, then you just use
> whichever regular release is current and then snag a long-term release
> when it becomes available.  Yes, it's more work, but that's life.
>
> -Ben Kaduk
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>