[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index


From: Greg Stein <gstein_at_lyra.org>
Date: 2003-02-20 11:25:05 CET

On Wed, Feb 19, 2003 at 12:14:11PM -0600, Karl Fogel wrote:
> Note that someone may discover and fix a bug on trunk, which we
> realize is in the branch too. In that case, steps 4 and 6 would be
> "reversed": the bug is fixed on trunk, and gets ported out to the
> release branch.

A good policy is that once an RM constructs the branch, *only* the RM can
commit to the branch. This prevents a bunch of yahoos from dropping changes
all over the branch while the RM is trying to test the thing. We've been
using this strategy in httpd land for a while.

[ in that setup, the RM lays down CVS tags across the codebase; the RM can
  then adjust tags to incorporate fixes; we haven't really done release
  branches so far in httpd, but that's just cuz cvs sucks ]

> > So, when I'm running dist.sh, if I specify the branch (branches/0.18) as
> > the REPOS-PATH then do I specify the VERSION from the commit in #1 above
> > or do I use some other revision number?
> That's a good question.
> Ideally, we'd want to use the head revision number, to reflect the
> head of the branch. But that could confuse people into thinking the
> release includes head trunk changes, when it doesn't.

The CHANGES file could just read:

Version 0.18.0 (released 19 Feb 2003, /branches/release-0.18 @ 4959)

That gives the user everything they need to know. Also, note that we *do*
create /tags/X.Y.Z as part of the process. As you state below, we can just
say "whatever is 'head' on that tag" and not worry about revision numbers.
For people that *are* interested in rev numbers, the CHANGES file would have
that info.

> How does this policy sound:
> subversion-0.18.0.tar.gz -- unpacks into subversion-0.18.0/,

I'm *so* fine with this strategy. The rev number-based tarballs are "neat",
but not as helpful for Mr End User.

> Meanwhile, for subversions built from a trunk working copy, we just
> have 'svn --version' print out the revision number. That is, instead
> of
> svn, version 0.17.1 (dev build)
> it will say
> svn, dev build, revision 4960
> or somesuch. This is possible now thanks to Philip's 'svnversion'
> program, which see.

I'm with Branko. We want to keep that saying "0.18.0+ (dev build)". If we
integrate svnversion, then we can include that info, too. But I wouldn't
recommend dropping the public version number.


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 Thu Feb 20 11:22:19 2003

This is an archived mail posted to the Subversion Dev mailing list.