Re: freebsd naming of releases

On Mon, 28 Mar 2005, Chris wrote:

> After what happened with 5.x releases would it be a good idea to name
> current releases different.  eg. 6.1-dev 6.2-dev onstead of
> 6.1-release.
>
> here is the reasoning behind my idea.
>
> When 5.1 and 5.2 were released many datacentres and individual users
> were using them as if they were standard releases probably because the
> FreeBSD docs say that they reccomend using releases in this order
> starting with most stable first.
> RELEASE
> STABLE
> CURRENT
>
> Now of course 5.1-RELEASE had no STABLE phase so there was less
> testing but many users would not have known this and simply seen
> 5.1-RELEASE, I think this is how the mistake came about so many people
> were using 5.x before it was marked STABLE and the same will happen
> again for 6.x if the same naming convention is used.  This would bring
> up a question such as which is more stable, 4.10-STABLE or 5.2-RELEASE
> since the latter is a RELEASE but the former is based on actual STABLE
> tree code whilst the latter is based on CURRENT tree code.  I hope
> others can make sense of what I am saying.  Please cc replies to me
> since im not subscribed to this list.

Here are things as I see them:

With the 5.x series, we ran into an issue where we needed more widespread 
testing of the branch before all of the bugs and edge cases could be 
shaken out (And the eventual marking of the branch as "STABLE"). 5-CURRENT 
took a number of years to develop, and no official testing release was 
about for users to effectively test and give feedback on [1] [2]. The 
notion that "CURRENT is not stable" worked against the first release of 
the 5.x branch as some users were reluctant to give the nightlies a try.

The solution of marking the 5.[0-2] releases as "Technology Preview 
Release" was very clever. It brought about testing on a whole slew of 
hardware, and the much needed feedback that allowed the 5.3 release to be 
the success that it was (At my workplace, we were so impressed by 5.3's 
performance that we upgraded all of our 4.x servers to it).

I believe it was Scott Long that sent out a roadmap that detailed the way 
things were going to be done for the next set of releases. There is a good 
amount of support behind the idea of releasing more often, and not putting 
several years between major version bumps. This should of course alleviate 
any doubt about how stable a .0 or .1 release really is. Search the list 
archives for more details on this and the thread that followed.

Andy

[1] The nightly iso images could do, but they are development releases, 
with features being added here and there, and are generally not as well 
suited for widespread testing as an official beta is.

[2] The Developer Preview doesn't count either because features and 
architectural changes were still being added/made at that point in time. 
The introduction of these features brought about new edge cases and bugs.

| Andre Guibert de Bruet | Enterprise Software Consultant >
| Silicon Landmark, LLC. | http://siliconlandmark.com/    >