Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Oct 1996 09:15:08 -0600
From:      rkw@dataplex.net (Richard Wackerbarth)
To:        Joe Greco <jgreco@brasil.moneng.mei.com>
Cc:        freebsd-hackers@FreeBSD.org
Subject:   Re: IP bugs in FreeBSD 2.1.5
Message-ID:  <v01540b00ae8aa9b6cd6d@[204.69.236.50]>

next in thread | raw e-mail | index | archive | help
>> I generally agree with your approach. However I would suggest that not
>> 2.1.5, but 2.1.x is the appropriate one for production.

My point here is that, although few changes have been made, we should
encourage people to upgrade from 2.1.5R to the present "-stable".

>> I also think that it would improve our image if we would call THAT release
>> 2.2.0 and have a formal PRE_RELEASE that we call 2.2 Beta.
>
>What is wrong with the ALPHA/BETA/RELEASE cycle (aside from the fact that
>it has been pretty much abused/ignored for the last few releases)?

"Pretty much"? I feel that it has been totally abused.

>Some of us are quite willing to test 2.2ALPHA if one is made available.

In a sense, the "SNAPS" are "Alpha". The primary thing missing is the
initial effort to define the release's feature target.

My point was that we SHOULD a reasonable amount of "shaking out" BEFORE we
drop the "RELEASE" label on something.

>
>However, I personally feel that in order to produce a more robust 2.2.5R,
>several months of beating on 2.2R will be necessary, and this is NOT going
>to be possible if the core team has a goal of December in mind for 2.2R.
>
>I would prefer to have a 2.2ALPHA in my hands TODAY, a 2.2BETA a month
>from now, followed by a 2.2R in December.  This would shake out obvious
>bugs in 2.2R, but would not be a sufficient period of time for robustness
>testing and bug elimination.

I concur. I also feel that we should continue to "support" (as in "have
readily available") a production grade version that has been shaken pretty
well.

If we have gone through the ALPHA/BETA/RELEASE cycle, then the "its in the
new (but unproven) release" is a reasonable answer to feature problems.

>But... when it comes right down to it, I don't care too much about how
>it's numbered, I just want to see something happen.  :-)

I do think that numbering has some impact on the perception that the public
has of the product.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v01540b00ae8aa9b6cd6d>