[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 0.35 => Beta => 1.0 schedule

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-12-05 02:56:16 CET

On Thu, 2003-12-04 at 19:56, kfogel@collab.net wrote:
> ... but as they approach a new release, many projects *do* start
> releasing bleeding edge tarballs for testing.

Right... but the key thing is that these are testing releases in
preparation for a new stable release, and their version numbers should
reflect this. Also, we should branch for 1.1 before we start putting
out tarballs for testing for 1.1, and we should make our testing
tarballs off of the 1.1 branch, not the trunk

> But at some point, IMHO sooner rather than later, we'll want to make
> dev tarballs available again, and when we do, they'll need names.
> What should those names be?

In my opinion? 1.1.beta1, 1.1.beta2, etc. When the beta period is done
and the release is ready to unleash upon the unwashed masses, you
release 1.1.0, and when you discover the horrible security hole in 1.1.0
that you need to patch, you release 1.1.1. (This is compatible with
RPM, incidentally. 1.1.beta1 is less than 1.1.0 is less than 1.1.1.)

Why do I like this better than 1.1.1-dev, 1.1.2-dev, etc., followed
eventually by 1.2.0? Because:

  * It makes it clearer that the 1.1 testing releases are associated
with the 1.1 release branch.

  * It doesn't invite people to accidentally (or deliberately) drop the
-dev suffix off the version number and possibly confuse other users with

  * It's more elegant. All integers are created equal; there's nothing
distinguished about odd numbers in the second spot.

(As to 1.1.0 versus 1.1 and 1.0.0 versus 1.0, I am slightly agnostic,
though I tend to favor the 1.0.0 form because it consistently uses three
version components.)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 5 02:57:24 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.