You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2004/04/15 20:25:34 UTC
Re: svn commit: r9362 - in trunk: . notes
breser@tigris.org writes:
> Modified: trunk/notes/releases.txt
> ==============================================================================
> --- trunk/notes/releases.txt (original)
> +++ trunk/notes/releases.txt Thu Apr 15 13:14:24 2004
> @@ -1,36 +1,43 @@
> Subversion Tarball Release Procedure
> ====================================
>
> -1. Create a release branch from the "golden" revision number:
> +1. When starting a new major or minor line create a release branch
> + from the "golden" revision number (otherwise skip to step 3):
>
> svn cp -rHEAD -m"Create release X.Y.Z branch" \
> http://svn.collab.net/repos/svn/trunk \
> - http://svn.collab.net/repos/svn/branches/X.Y.Z
> + http://svn.collab.net/repos/svn/branches/X.Y.x
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.
Hmm, and now that I think about it, do the instructions for creating
long-lived lines belong in releases.txt at all?
And finally :-), wherever they're documented, it's probably worth
pointing out explicitly that "X" and "x" mean very different things in
these examples, since the latter is a literal.
> - (Note that only the release manager commits to the branch;
> - everyone else continues working on trunk, and the release
> - manager ports changes across only if absolutely necessary.)
> + All release of the X.Y line will come out of this branch.
> + Changes from trunk will be merged based upon compatability
> + rules and voting as explained in HACKING.
>
> -2. Tweak trunk/CHANGES to contain all the latest changes.
> +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?
> - 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.
> - Version X.Y.Z (released XX Month 200X, from revision XXXX)
> + You'll commit this change along with the change in step 3.
> +
> +3. Tweak trunk to have a new CHANGES section.
> +
> + a) Begin a new section at the top of the CHANGES file with:
> +
> + Version X.Y.Z (released XX Month 200X, from branches/X.Y.Z)
> http://svn.collab.net/repos/svn/tags/X.Y.Z
>
> - b) Bump the version numbers in svn_version.h and CHANGES.
> -
> - c) Commit.
> + b) Commit.
>
> -3. Create a working copy (wc) from the release branch:
> +4. Create a working copy (wc) from the release branch:
>
> $ svn co http://svn.collab.net/repos/svn/branches/X.Y.Z
>
> -4. The branch stabilizing week
> +5. Merge fixes and changes from trunk.
>
> Only very important bugfixes are allowed to merge from the trunk to
> - the release branch. A decision of a merge happends in the Dev
> - mailing list.
> + the release branch. A decision of a merge happends in the STATUS
> + file as documented in HACKING.
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.
> In the following example, we pretends to merge revision 7868 into
> the release branch:
> @@ -44,14 +51,17 @@
> $ svn ci -m "Merge r7868 into the 0.34.0 branch"
>
> c) cd to your wc for http://svn.collab.net/repos/svn/trunk and add
> - a note under the merge section like this in the CHANGES file:
> + a note under User-visible changes or Developer-visible changes.
> +
> + * fixed: Java bindings compilation.
>
> - Merged revisions after release branching:
> - * r7868 - Java bindings
> + Note: CHANGES is maintained on the trunk because future releases should
> + have past releases CHANGES entries. It will be merged onto the branch
> + just before a release.
Nice point.
> d) Commit
>
> -5. It's release time, so cd to the release branch's working copy.
> +6. It's release time, so cd to the release branch's working copy.
>
> a) Make sure your release branch wc has the following packages
> extracted into the root of the wc tree:
> @@ -92,15 +102,16 @@
> (The book maintainers keep those files up to date, so the
> release manager doesn't have to rebuild the book.)
>
> -6. Merge CHANGES and svn_version.h into the release branch. Do it the
> - same way as described in section 4 in this document when merging
> - fixes to the release branch.
> +7. Merge CHANGES into the release branch. Do it the same way as described in
> + section 4 in this document when merging fixes to the release branch.
> +
> +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?
> -7. Run './dist.sh [ARGS ...]' (see dist.sh for details about ARGS)
> Watch dist.sh's output to make sure everything goes smoothly; when
> - it's done, you'll have 'subversion-X.Y.Z.tar.gz' in the cwd.
> + it's done, you'll have 'subversion-X.Y.Z.tar.gz' and
> + 'subversion-X.Y.Z.tar.bz2' in the cwd.
Ah, much needed addition, yes.
> -8. Test the tarball:
> +9. Test the tarball:
> a) tar zxvf subversion-X.Y.Z.tar.gz; cd subversion-X.Y.Z
> b) ./configure
>
> @@ -150,8 +161,12 @@
> subversion/clients/cmdline/svn co \
> http://svn.collab.net/repos/svn/trunk
>
> -9. Upload the tarball to /usr/www/docroot/tarballs/ on svn.collab.net,
> - then link to it from subversion.tigris.org.
> +10. Use GPG to sign release.
> +
> + [Details to be filled in later].
Yup, but agree it's good to have the placeholder now.
> +11. Upload the tarball to /usr/www/docroot/tarballs/ on svn.collab.net,
> + then link to it from subversion.tigris.org.
>
> The ability to upload a public, automatically approved tarball
> requires the "Project Document - Approve" permission, which is a
> @@ -175,18 +190,39 @@
>
> f. Click Submit
>
> -10. Move branch into the tags directory in the repository.
> +12. Copy branch into the tags directory in the repository.
>
> - svn mv -m "Moved Release X.Y.Z branch to tags/." \
> - http://svn.collab.net/repos/svn/branches/X.Y.Z \
> + svn cp -m "Make tag for release X.Y.Z." \
> + http://svn.collab.net/repos/svn/branches/X.Y.x \
> http://svn.collab.net/repos/svn/tags/X.Y.Z
>
> - Now that the release is public, no more changes can happen on that
> - branch. If we discover problems with the release, then we make a
> - new branch (with the minor version number incremented), apply
> - fixes, and go through the release process again.
> +13. Switch your working copy to the tag.
> +
> + svn switch http://svn.collab.net/respos/svn/tags/X.Y.Z
> +
> +14. Copy svn_version.h.dist (that dist.sh made in the top level of your wc)
> + to subversion/includes/svn_version.h and commit.
> +
> + cp svn_version.h subversion/include/svn_version.h
> + svn commit -m "Update svn_version.h to match tarball." \
> + subversion/include/svn_version.h
> +
> + Now that the release is public and the tag matches the tarball, changes
> + are not allowed on the tag. If we discover problems with the release,
> + then we will fix them on the branch we did the release off of and do a
> + new release.
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".
Rest looks good to me.
Thanks for taking this on; let me know what you think about the
maintaining-a-line vs releasing-a-line distinction.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r9362 - in trunk: . notes
Posted by kf...@collab.net.
Ben Reser <be...@reser.org> writes:
> Probably not, I noticed the same problem. I just was trying to get the
> releases document in a state that matches
Ah, understood.
> > > +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. :)
Sorry :-).
> 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.
+1
> > 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. :)
Yup, saw the pointer to HACKING -- was just saying that therefore even
less of that material needs to be included in releases.txt.
> 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.
Oooh. Urk. Thanks.
> > 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
Cool.
/me bows in gratitude toward He Who Cleaneth The Augean Stables.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r9362 - in trunk: . notes
Posted by Ben Reser <be...@reser.org>.
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 <be...@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