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...
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.
Having a development and stable branch is in some ways a delight and
at other times painful. It all depends on how much developer energy
is available and how many people are interested in doing backports.
Note that with httpd we have a 2.1 branch (== CVS HEAD) and a 2.0
branch, the 2.0 branch only receives backports. IOW, all development
happens on 2.1 first. This keeps 2.0 nice and stable, which should
allow easier releases of 2.0.
I could see us have a similar setup in subversion by renaming trunk to
devel and branching 1.0 to svn-1.0. We can introduce 1.1 either by
branching svn-1.0 to svn-1.1 at some point, doing a bunch of backports
of devel, or, my preference, branch devel to svn-1.1.
Release wise, we can always do a branch from svn-x.y to svn-x.y.z,
change the version string (stripping the -dev), and tagging it as
svn-x.y.z. If we feel a release should be beta or alpha even, we
should reflect that in the version and the tag.
Development releases could be just tarballs of snapshots, created
directly from devel. These will all be named svn-x.y.z-dev, because
when we feel devel is ready for the masses, we branch it to svn-x.y
and start doing (alpha, beta, GA) releases from there. Ofcourse
devel is bumped up a minor number after the branch (or a major number).
With this scheme there is no need to have even/odd numbering of
versions. devel promotes to stable, and devel gets a the next number.
The new stable branch doesn't get a version number change just because
it branched from devel.
Thoughts?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 5 11:33:51 2003