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.
