On Sat, Dec 13, 2003 at 09:54:00AM -0500, Greg Hudson wrote:
> Stable releases are named subversion-x.y.z, no odd/even
> Not-yet-vetted branch releases are named subversion-beta-x.y-rXXXXX
> (or subversion-alpha-x.y-rXXXXX if we feel they're of alpha quality)
> Snapshots off the trunk are named subversion-snapshot-rXXXXX
> We discourage binary packaging of anything other than stable releases
> So, we get:
> subversion-snapshot-r10135 from trunk
> subversion-snapshot-r10242 from trunk
> <branch point for 1.1>
> subversion-beta-1.1-r10321 from branch
> subversion-snapshot-r10400 from trunk
> subversion-beta-1.1-r10412 from branch
> subversion-1.1.0 from branch
> I like this because:
> * Stable releases live in a different version space from everything
> else, and that version space reflects the branch structure which exists
> for them. Odd/even would be a distortion of the branch structure.
> * It's easy to identify where unstable releases came from in the
> repository, and what they are.
I can't understand why we would want to do snapshots from the trunk?
Is there any real reason to do this? A snapshot from the trunk isn't
going to be particularly special... All it means is someone did an
export, followed the release procedures to some degree (no branching,
no changing the version, but running autogen etc...). Further, what
exactly is the point for releasing a snapshot that you don't want people
to package? I can understand a beta, you want people to test it and to
some degree that means packaging.
As a packager I can tell you the following is going to happen. If you
put up a snapshot tarball, it'll end up showing on sites like freshmeat
or end users will just find it on your website, then I'll get several
emails asking when I'm going to be packaging the snapshot. Some
packagers will either give in and just do it or tell people to go away.
Packagers need to package betas however, if for no other reason than to
simply get a chance to find errors in your installation routines that
create problems for packaging. But also to allow them to be prepared
for the release of the new version relatively soon after you do the
You are right however that kfogel's proposal would lead to non-linear
version numbers. Which would be a real nightmare from a packaging
standpoint. Somehow I missed that when I read his email earlier. But
that's just not acceptable. I'd end up having to use epoch's on the
rpms (which I hate doing because to the end user it seems magical that
1.1.1 is upgrading over 1.3.1)
Drop the snapshot releases and I guess I like your proposal a little
better. Though honestly I'm not sure I'm fond of trying to include repo
revisions in the package names. But if it avoids a versioning nightmare
I guess I can live with it.
+1 for this without snapshots
-1 for kfogel's proposal that I previously +1'ed.
Ben Reser <email@example.com>
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Dec 14 00:30:34 2003