[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 Stein <gstein_at_lyra.org>
Date: 2003-12-05 10:14:58 CET

On Thu, Dec 04, 2003 at 08:56:16PM -0500, Greg Hudson wrote:
> 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

People are going to want to try the new features, and we are going to
*want* them to try them out. This is going to be necessary *before* we
create a 1.1 branch. Thus, I believe your assumptions above will not work
out for us very well.

> > 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?

I think that we'll have, say, a dozen dev/test release tarballs. Maybe
more? Hard to say -- it mostly depends upon how much we try to chew off in
the "next release".

> In my opinion? 1.1.beta1, 1.1.beta2, etc. When the beta period is done
>...
> (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.)

I also prefer consistent triplets(*), and along that line, I dislike the
1.1.betaN format. The even/odd works well because we can do 1.1.0 thru
1.1.20, and then pop it to 1.2.0 for the stable release.

Cheers,
-g

(*) and to that end, I dislike the tags/ directory containing a mix of 2-
and 3-number version names.

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 5 10:18:06 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.