[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: Kevin Pilch-Bisson <kevin_at_pilch-bisson.net>
Date: 2003-12-05 18:37:26 CET

> -----Original Message-----
> From: Sander Striker [mailto:striker@apache.org]
> Sent: Friday, December 05, 2003 2:33 AM
> To: dev@subversion.tigris.org
> Subject: Re: 0.35 => Beta => 1.0 schedule
> On Fri, 2003-12-05 at 02:56, 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
> Sheesh, that's some thread...

Sure is.
> I'll add my thoughts. First of all, the -dev prefix in httpd is there
> to tell you the code you are using, was not released as stable when you
> grabbed and built it. svn --version uses this property aswell AFAICT,
> and I rather like it. Greg Hudson mentioned people stripping the -dev,
> but IMO, that's the same as just arbitralily modifying the version
> header. If this is something that people frequently do, that's a
> problem in itself.

My personal problem with the -dev approach that we/httpd/apr use is that I
can never remember whether 1.0-dev is dev leading toward 1.0, or based on

Snip rest of Sanders proposal.

I don't like the idea of using -dev in the name, so just to add to the mix,
here's my proposal.

Why don't we have:
* released versions with version numbers.
* snapshot releases, with just a datestamp or a revision number.

So you would have subversion-1.0.tar.gz, and

I think this scheme avoids the confusion about version numbers, and makes it
clear that this is an unstable release?

-- Kevin.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 5 18:38:51 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.