Josh Elser 2013-05-28, 00:39
Christopher 2013-05-28, 01:37
On 05/27/2013 09:37 PM, Christopher wrote:
> On Mon, May 27, 2013 at 8:39 PM, Josh Elser <[EMAIL PROTECTED]> 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. 
>> 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
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
> 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?
>>  http://svn.apache.org/repos/asf/accumulo/tags/1.5.0/pom.xml
> 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/build.sh, 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