Re: [RFC] 3.1 branching

Alex Rousskov wrote:
> On Thu, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote:
>> 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
>
> Sorry, I should have looked there too. I was talking about
> http://www.squid-cache.org/Versions/
>
>> 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.
>
> I will need a flow chart tool to grok 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.
>
> I am not an expert on this, but AFAIK, there are several popular models
> including odd/even, devel/stable, current/release. Some do release
> candidates, but it is often just an informal announcement (e.g.,
> snapshot such and such is a release candidate). Many offer VCS access
> and, hence, can do snapshots (as a convenience for the user). But the
> main theme seems to be a simple single threshold (if you do not count
> VCS).
>
> The above scheme is pretty much the same as devel/stable approach many
> projects use. It should be familiar to users and developers alike.
>
> The key here is to make it as simple and well defined as possible. I
> think our scheme is too complex and confusing because we are trying to
> piggyback too many things onto a version label and make it too
> fine-grained. This hurts both users and developers.
>
> Personally, I have never seen other projects stuffing version numbers
> with STABLE. It is strange to look at, it is longer to type, and harder
> to auto-process. IMHO, version should only contain version numbers.
> Everything else is metadata that does not belong there. I am sure there
> are projects out there that do similar silly stuff though.
>

Just brain dumping at 4am, but, how about this:

stuff goes into HEAD (3-)
... after a period we branch (3.1) with features from HEAD
... fix all known bugs and release 3.1.0-rc1
... if confirmed stable gets officially released as 3.1.1
... any critical bug found, or large accumulation of minor ones causes
3.1.2 etc
... work continues on HEAD for next branching point of (3.2).

Amos

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