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.
Cheers,
-g
--
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