[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: John Szakmeister <john_at_szakmeister.net>
Date: 2003-12-05 02:37:35 CET

On Thursday 04 December 2003 20:26, Jani Averbach wrote:
> On 2003-12-04 18:08-0600, kfogel@collab.net wrote:
> > Regarding that other topic, numbering schemes:
>
> ...
>
> First of, I am happy with even/odd scheme - users have to always find
> out what is the stable version and what is the development version (if
> there is any). If you just start poking around ftp server, and grab
> what ever you first find, you are digging blood from your
> nose. Moreover, what ever the schema will be, it should be documented
> very top of README/INSTALL so I really don't see an issue here.
>
> However, may I introduce my own proposal? =)
>
> > Thus we'd have a stable maintenance line like this
> >
> > subversion-1.0.0.tar.gz
> > subversion-1.0.1.tar.gz
> > subversion-1.0.2.tar.gz
> >
> > And development releases like this:
> >
> > subversion-1.1.0-dev.tar.gz
> > subversion-1.1.1-dev.tar.gz
> > subversion-1.1.2-dev.tar.gz
>
> How I read that:
>
> "subversion" "dev release for 1.1.0" , which might/will be stable some day.

Glad I'm not the only one who read it that way. :-)

> So, I propose that the "dev" will prefix release number, in that way
> the first thing that will hit your brains is that this is "dev",
> after that you will find out the release number, package format, etc..
>
> subversion-dev-1.1.0.tar.gz, subversion-dev-1.1.0.rpm...

If we're going to make development releases, I think I prefer this way.

-John

---------------------------------------------------------------------
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:33:20 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.