Henrik Nordstrom wrote:
On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote:
PRE, to me, means "we think it is stable, what do you think?".
A development release, to me, means "we are done adding features, please
help us with testing and polishing". And yes, I know that the
definitions at http://www.squid-cache.org/Versions/ are somewhat
different. IIRC, I failed to convince others that mine are better :-)
You are off-by-one from what we normally use
DEVEL - We are still adding features, but this release is beleived to be
reasonably stable suitable for evaluating what has been done so far.
PRE - We are done adding features. Please help us hunting down the last
bugs.
RC - No more known bugs to fix. We think it's stable. Please verify.
STABLE - We think it's stable production release.
DEVEL releases is rarely needed as the nightly snapshot releases serves
this purpose well. Came to light during the very extended Squid-3.0
development cycle with lots of major restructuring and destabilization
taking place..
The non-major but important bugs can be fixed during DEVEL and PRE
cycles. Branching is about features not bugs.
Agreed, except I do not think we should have any known important bugs
when doing the first PRE (if we do PRE at all).
Yes. It's not much use in releaseing a PRE with known major blockers.
Well, we all seem to agree on no bugs above a certain level, but differ
as to what the maximum rating should be :-)
I've been basing my standards on the bugzilla importance labels.
PRE requiring:
0 'blocker', 'critical', 'major'
judgement call on those labeled 'normal' or lower (few as possible)
My PRE list is the one linked from RoadMap under "bugzapping".
(all bugs >minor, either existing in or targeted at a fix 3.1)
My RC list extends that to include the 3.0 bugs, so 3.1.RC1 won't go out
until there are no big bugs inherited from 3.0.
Maybe we should call a bug sprint with PRE1 release.
Amos
--
Please use Squid 2.7.STABLE4 or 3.0.STABLE9
