accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: SCM Section of 1.5.0 pom
Date Tue, 28 May 2013 01:48:05 GMT

On 05/27/2013 09:37 PM, Christopher wrote:
> On Mon, May 27, 2013 at 8:39 PM, Josh Elser <> wrote:
>> Poking around at the changes that Christopher made in regards to making
>> releases, I noticed in the 1.5.0 tag from subversion, the 'scm' section
>> still has connection, developerConnection and url pointing to RC5. [1]
>> I assume this was just an oversight. Is this something that we should just
>> be changing on that tag since the vote passed?
> Hrmm. We definitely should not edit the tag after the vote passes. It
> should remain exactly as it was when it was voted on, as it affects
> signatures, and everything.
> So, this gets updated by the maven-release-plugin automatically. I
> don't think it's that important. It does get used by the
> maven-site-plugin. This field is used to generate a page on the
> maven-site that tells users how to access the source code. If we ever
> start generating the maven-site, we're going to want that to be
> correct. However, we don't want to make the release process harder by
> going back to manual ways of doing things that are automated by
> maven-release-plugin.
This was exactly what I was thinking about. It'd be great to get the 
site functioning again.

And instead of hiding another inline below: beast-mode, dude. Lots of 
great information. IMO, the info merits its own page. I'll make a ticket 
to add it to our page, building out on the "source code & developers 
guide", I think.

> I suppose there are two options to deal with this specific "gotcha"
> (svn-specific... git may be different... somebody else will have to
> advise for that):
> 1) never delete an RC tag, so it can still be referenced with the RC#
> suffix, even though it's identical to a second "tag" (eg. use "svn cp"
> instead of "svn mv" after a release vote passes).
> 2) tell the release-plugin to create the tag in its final location,
> then "svn mv" it to the RC name manually, then "svn mv" it back if it
> passes.
> Maybe we should request a feature for the maven-release-plugin to
> support release candidates better?
>> A bit of a follow-on, mostly for Christopher. If you get hit by a bus, any
>> instructions for the rest of us on any other "gotchas" that you came across?
>> Is this worthy of a page (public or just developer-based) devoted to the DOs
>> and DONTs in making a release?
>> [1]
> The build is pretty much completely automated and self-documented (it
> activates the correct profiles automatically). To actually do a
> release, the steps are pretty much, "execute `mvn release:prepare
> release:perform`". For convenience, I added this command to
> assemble/, but really, as long as you have all the
> prerequisites to build all the desired artifacts, the build is pretty
> much automated from start to finish.
> I suppose I could add some notes:
> DO use gpg-agent.
> DO set a default key in ~/.gnupg/gpg.conf if you have more than one secret key.
> DO set a gpg-agent cache timeout long enough to execute the build, and
> cache your passphrase in gpg-agent before you build.
> DO use a system with all the prerequisites to build native libraries,
> RPMs, and DEBs, as well as thrift (including ruby, c++, python, and
> java support).
> DO make sure the correct version of all the java binaries are on the
> path, and none from other versions that may be installed (like
> javadoc... which produces very different documentation, depending on
> the version).
> DO cache your SVN credentials (I recommend using subversion-gnome to
> put your passphrase in gnome-keyring rather than let subversion store
> it in plain text).
> DO build in an account where your username is the same as your Apache ID.
> DO update the CHANGES file prior to building, in a separate commit.
> DO close the staging repository so no further artifacts can be
> deployed to it, and so others can view it for voting.
> DO edit the recommended tag, when prompted by the
> maven-release-plugin, to include the specific tag number (the default
> when it prompts is simply $version-RC, but you want $version-RC#).
> DON'T make things difficult by adding a bunch of manual steps to the
> build process
> DON'T build on a dirty workspace (use a clean checkout)
> DON'T try to do a release from an IDE (use the command line)
> DON'T try to install all the LaTeX packages manually (use `yum install
> texlive*` or equivalent)
> DON'T build remotely, unless you're using screen (if the SSH
> connection dies, you won't know what state your workspace is in, or
> whether it has already made commits to SVN without checking)
> DON'T accidentally release the wrong staging repository.
> There's some additional SVN gotchas to worry about:
> 1) The maven-release-plugin creates 3 commits, if it is successful:
> one to change the version number to the release version, one to copy
> the branch with the release version to the tag, and one to change the
> version number in the branch to the next SNAPSHOT version. These
> changes will interfere with merges from branch to trunk. It would be
> best to merge these 3, as well as the commit to edit CHANGES, all to
> trunk as a --record-only merge, so that future range merges (as in
> `svn merge -r 1:HEAD branches/1.5/ trunk/`) go smoothly. To do this,
> identify the specific commits, C1,C2,C3,C4, and merge them like: `svn
> merge -r C1,C2,C3,C4 --record-only branches/1.5/ trunk/`, and then
> commit the changes in trunk/.
> 2) To roll back a failed RC in SVN, do a reverse merge of the 3
> maven-release-plugin commits, as well as the commit to edit the
> CHANGES file, onto itself in reverse order, with a '-' sign prefixed
> to each, as in: `svn merge -c -C4,-C3,-C2,-C1 .`; you'll want to do
> this on a checkout of the whole svn repository, and not just your
> branch, because one of those commits represents an RC tag, which is
> outside of your branch, and it's easier to delete it in the same step,
> than figure out which of the three commits represents the tag, ignore
> it during the reverse merge, and separately delete the RC tag. After
> you do the reverse merge, commit it. This single commit (I'll call C5)
> represents squashing C1-C4, and reversing them all, but it will affect
> future merges from the branch to trunk, so you'll want to do a
> --record-only merge of C5 onto trunk from the branch, to ensure clean
> range merges from now on (see previous paragraph).
> --
> Christopher L Tubbs II

View raw message