Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> SCM Section of 1.5.0 pom


Copy link to this message
-
Re: SCM Section of 1.5.0 pom

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. [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] 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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB