Re: [RFC] 3.1 branching

Alex Rousskov wrote:
> On Wed, 2008-09-24 at 12:21 +0200, 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.
>
> Oh boy, I forgot about yet another undocumented stage -- RC! I wonder
> what "PRE" stands for then. Pre-RC?! This is just plain wrong.

'tis documented:
http://www.squid-cache.org/Devel/release-process.html

Although..
from 3.1 - step 1 and 4 are joined, so step 2+ happens parallel to HEAD
without locking other new features.
and I have not exactly been closely following step7 for 3.0. To pump
through the biggest bug fixes faster.

>
>> 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 DEVEL label is not needed indeed, but I was talking about code
> states. I understand now that you use the PRE state for a different
> purpose. Please note that your definitions of DEVEL and PRE differ from
> the ones on the web site.
>
> The most annoying thing, IMO, is that the official and your definitions
> above have two fuzzy lines for DEVEL and PRE states: stability and
> features. One fuzzy line is tolerable, but two make things really
> confusing.
>
>>>> 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.
>
> But your definition above says we are still hunting down some bugs. It
> does not say there are no major bugs left.
>
> How about this:
>
> Trunk: Experimental code and new major features are being added. Use
> daily snapshots (e.g., HEAD-YYYYMMDD). No label.
>
> ... time passes, more features are added ...
>
> Branching point (e.g., 3.1): All major features are in. Use daily
> snapshots (e.g., 3.1-YYYYMMDD). No label.
>
> ... time passes, all known major bugs get fixed ...
>
> First numbered release (e.g., 3.1.0): All known major bugs fixed. Could
> be labeled a "beta" or "development" release if needed.
>
> ... time passes, more beta releases are made, with fewer bugs ...
>
> Branch first marked as "stable" (e.g., 3.1.5): The last numbered release
> turned out to be stable!
>
> ... time passes, the stable branch is maintained ...
>
> Branch marked as "end of life" or "no longer supported".
>

Suites me either way. Some of the users at AusMeet commented on the
confusion of calling a release 3.0.STABLEx when a month later it
obviously wasn't.

I only have one question: how well does that release numbering model
match the other OSS projects using the same numbering system? We don't
want to set our own method and meaning when there is already a common
way to get confused with.

Amos

-- 
Please use Squid 2.7.STABLE4 or 3.0.STABLE9