Re: [RFC] 3.1 branching

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.

Cheers,

Alex.
Received on Wed Sep 24 2008 - 16:35:00 MDT