On Thu, Apr 15, 2004 at 03:25:34PM -0500, kfogel@collab.net wrote:
> Since this is about the creation of a long-lived line, it probably
> doesn't make sense to call it a "release branch", either in the
> explanatory text or the log message.
Well I still think of the 1.0.x branch as a release branch. All 1.0.x
releases are done off it. This is of course distinct from the meaning
the document gave it in the psat.
> Hmm, and now that I think about it, do the instructions for creating
> long-lived lines belong in releases.txt at all?
Probably not, I noticed the same problem. I just was trying to get the
releases document in a state that matches
> > +2. Bump the version numbers in svn_version.h on trunk.
> Well, not for a 1.0.2 release when trunk is already on 1.1.x, right?
That's why you skip to step 3 as it says in step 1. :)
> > - a) Begin a new section at the top of the file with:
> > + Note that this should be the next major/minor line we plan on doing.
> > + E.G. if you're making the 1.1.x branch then the svn_version.h in trunk
> > + should reflect 1.2.0.
>
> Hmmm. Yah.
>
> I get the feeling we're mixing two documents here. There's "How do we
> maintain different development lines?" (which probably belongs in
> HACKING, to the extent that it's not documented there already), and
> then there's "How to do a release?", which is only about releasing.
> notes/releases.txt should probably confine itself to the latter.
That's fine. We should split the documents... The first half or so of
the releases.txt file aren't really necessary to know just to make the
tarball.
> IMHO, no need for us to talk about the merging guidelines much in
> releases.txt. We have a self-sustaining voting system, the release
> manager needs to know how it works and be able to evaluate the STATUS
> file, but the merges themselves are not part of the release process
> per se.
Thus the pointer to HACKING. :)
> > +8. Run './dist.sh -v X.Y.Z -r 1234 -pr branches/X.Y.Z'
>
> It's still true that if someone builds an executable from the "release
> branch" during the time between this step and the actual release, that
> the 'svn --version' output of that executable will be distinguishable
> from the 'svn --version' output of the Subversion that gets released
> later, right?
Correct. dist.sh changes the svn_version.h from a development version
(this commit fixed a bug in the sed that wasn't entirely doing it
properly). The commit later that changes the svn_version.h actually
happens on the tag. The branch *NEVER* shows as a release build.
Which reminds me, the comments in svn_version.h are wrong. They have
instructions that don't match what we've actually been doing. Forgot to
commit that fix.
> Ah! Interesting solution. And perfectly fine, IMHO. The point of a
> tag is not that it can never have any commits at all, but that there
> is a moment after which one can say "There should be no *more* commits".
*nod* I'd rather the only commit that ever happens on the tag is the one
that creates it. But it's too much effort to make that happen and I
think it's more important to ensure that the branch never has something
that looks like a release on it. Because a follow up commit could make
the branch different than the release without fixing the svn_version.h
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 16 01:42:21 2004