incubator-blur-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Blur Wiki] Update of "HowToRelease" by TimWilliams
Date Fri, 30 Aug 2013 02:30:00 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Blur Wiki" for change notification.

The "HowToRelease" page has been changed by TimWilliams:

New page:
{{{#!wiki caution
'''WARNING - Do Not Use!'''

These are docs borrowed [ripped off] directly from Whirr.  They don't yet relate to Blur.
 A work in progress...

This page describes how to make a release of Blur. It is based on a combination of the [guide
for Tapestry|] (thanks to the Tapestry
team for sharing this!), and the [Hadoop release process|].

See also [Blur: To Contribute] for more background on building Blur. 

*TODO: These instructions need updating to reflect
regarding i) key length, ii) signature strength.* 

= First time as a release manager. =

# Generate [PGP code signing keys|]

# Ensure that your [PGP signing keys|]
are available in: More details can be found [here|].

# Copy the new KEYS file to the release folder /www/ on

If you are not already a member of the [Web Of Trust|]
(WOT) it would be a good idea to do so. (contact one of the prior release managers, e.g. Tom,
Patrick, etc...). You can read more about key signing [here|].

You need to be a member of the "incubator" unix group on Ask for help on
the incubator general@ list. Here's an example 

Ensure that you have setup your ssh keys on, otherwise you'll have to enter
your login password a number of times (best use ssh-agent for this as well). A good overview
of this process can be found [here|]
(ssh-copy-id and ssh-agent in particular)

=  Create a Release Series Branch =

*TODO: Update to use git the next time a new release series is created.* 

This only needs doing if this is the first release in a series (X.Y.0). 

* Update CHANGES.txt in trunk to replace Trunk (unreleased changes) with Release X.Y.0 - YYYY-MM-DD.
svn commit -m "Preparing for release X.Y.Z" 
* Create a branch for the release series: 
svn copy \ -m "Branching for X.Y releases"

* Add back Trunk (unreleased changes) to CHANGES.txt in trunk. 
* Bump the version number in trunk (the update-versions script mangles the whitespace in the
root XML element): 
for file in $(find . -name pom.xml); do 
sed -i "" -e "s/0.1.0-SNAPSHOT/0.2.0-SNAPSHOT/" $file; 
* Bump the version in src/site/xdoc/index.xml. 
* Bump the version in src/site/xdoc/blur-in-5-minutes.xml. 
* Bump the version in src/site/site.xml. 
* Commit these changes to trunk. 
* Checkout the release branch 
svn checkout 

=  Update the Release Branch =

The version number in the release branch ends in -SNAPSHOT, but we need to remove this for
the release. For example, 0.1.0-SNAPSHOT needs to be changed to 0.1.0 

for file in $(find . -name pom.xml); do 
sed -i "" -e "s/0.1.0-SNAPSHOT/0.1.0/" $file; 
* Fix the version numbers in src/site/xdoc/index.xml, src/site/xdoc/blur-in-5-minutes.xml,

=  Run Tests =

Run all the unit and integration tests (which means you should have cloud credentials to run
on a cloud provider) with the following: 

mvn clean verify -Pintegration -Posgi -DargLine='-blur.test.provider=<cloud-provider>
-blur.test.identity=<cloud-provider-user> -blur.test.credential=<cloud-provider-secret-key>'


=  Generate the Release Notes =

JIRA has the ability to generate release notes automatically (this is why it is so important
to keep the fix version number accurate). 

Manually check this list for accuracy! I've repeatedly seen closed bugs that were not fixed
(i.e., duplicate) marked with a fix version, so that they incorrectly show up in this list.
Find those, edit them to remove the fix release (only actually fixed bugs should have a fix
release) and re-run the report. 

Select the correct version, in HTML format. 

Paste the notes to the top of _src/site/xdoc/release-notes.xml_. Check this into trunk and
the branch. 

Wrap the title ("Release Notes - Blur - Version X.Y.Z") inside an <h1> element. 

=  Build and Deploy Artifacts =

Create a maven settings file _~/.m2/settings.xml_ with the following content: 


Build the artifacts: 
mvn site -Posgi 
mvn package assembly:assembly -Posgi 

The following command deploys the artifacts, checksums, and signatures (you will need to enter
a GPG passphrase) to the [Apache Staging repo|].

mvn deploy -Ppackage -Pdeploy -Pjavadoc -Posgi 

If this step fails with an _Access denied_ error check that you have the required permissions
on [Nexus|]. 

Login to using your Apache credentials. Click on *Staging* on
the left. Then click on *org.apache.blur* in the list of repositories. In the panel below
you should see an open repository that is linked to your username and IP. Select this repository
and click *Close*. This will close the repository from future deployments and make it available
for others to view. 

=  Copy Release Artifacts =

The artifacts that end up in the distribution directory are the source and binary distributions
(along with their checksums and signatures), so they need to be copied from the Maven repo
to the release directory on so folks can vote on them: 

*TODO: update the instructions, the artifacts should be placed in a subdirectory rather than
all at the toplevel* 

mkdir ~/public_html/blur-$VERSION-candidate-0 
cd ~/public_html/blur-$VERSION-candidate-0 
for ext in "" .asc .md5 .sha1; do 
wget --no-check-certificate[YOUR
REPOSITORY ID]/org/apache/blur/blur/$VERSION/blur-$VERSION-src.tar.gz$ext 

Now we need to create the binary distribution checksums and signatures (since Maven doesn't
currently do this - if anyone know how to fix this, then please let us know!): 

cd target 
md5 blur-$VERSION.tar.gz > blur-$VERSION.tar.gz.md5 
shasum blur-$VERSION.tar.gz > blur-$VERSION.tar.gz.sha1 
gpg --armor --output blur-$VERSION.tar.gz.asc --detach-sig blur-$VERSION.tar.gz
scp -p blur-$VERSION.tar.gz*$VERSION-candidate-0 

=  Sanity Check =

Download the artifacts and try out some of these things: 
* Blur in 5 minutes or the [quick start instructions|]

* Check the MD5 checksums 
* Licensing check: (download [RAT|] and run java -jar apache-rat-*.jar
on the Blur tarballs. Known violations include generated files (e.g. docs), .confluence files,
.json files, and a few plain text files like CHANGES.txt. 

=  Commit and Tag =

Commit changes in the branch and create a release tag: 

git commit -am "Preparing for release X.Y.Z" 
git push origin branch-X.Y:branch-X.Y 
git tag -a release-X.Y.Z -m "Blur X.Y.Z release" 
git push origin release-X.Y.Z 

=  Run the Vote =

Run the vote on the dev@blur. 

Here is an example email: 

To: "Blur Developers List" <> 
Subject: [VOTE] Release Blur version X.Y.Z 

This is the first release candidate for Apache Blur, version X.Y.Z. 

It fixes the following issues:

*** Please download, test and vote by [3 working days after sending]. 

Note that we are voting upon the source (tag), binaries are provided for convenience. 

Source and binary files:[YOUR USERID]/blur-X.Y.Z-candidate-0 

Maven staging repo:[YOUR REPOSITORY ID] 

The tag to be voted upon:;a=tag;h=[HASH] 

Blur's KEYS file containing PGP keys we use to sign the release: 


The release needs 3 +1 votes from the PMC. 

=  Roll Out =

Assuming the vote passes, the release can be rolled out as follows: 

== Move Artifacts into Place ==

This step makes the artifacts available on the mirrors. 

cp -r ~/public_html/blur-$VERSION-candidate-$CANDIDATE /www/$VERSION

cd /www/ 
chgrp -R blur blur-$VERSION 
chmod -R g+w blur-$VERSION 
rm stable 
ln -s blur-$VERSION stable 
rm -r /www/$PREVIOUS_VERSION # remove older versions 

The last line is to remove the _previous_ version, since only the most recent version on a
particular branch should be in the dist directory (older versions are archived automatically,
see and

Log in to, click on *Staging* on the left. Select the repository
that you closed earlier, and click *Release*, using a description like "Apache Blur X.Y.Z
artifacts". This will make the artifacts publicly available. 

== Build and deploy documentation ==

*TODO: this section needs updating following the change to svnpubsub in BLUR-???. See the
"Build and Deploy Site" section below for guidance.* 

mvn site-deploy 

== Add the Next Release to JIRA ==

Add the next version number (e.g. 0.2.0 after 0.1.0) to JIRA using this 

In JIRA mark the released version as "released" on the "manage versions" page. Be sure to
fill in a date if not already specified. 

== Wait 24 Hours ==

It takes up to 24 hours for all the mirrors to sync, so don't announce the new release just

== Build and Deploy Site ==

Update the top level site by checking out (note
that this is still in svn) and editing src/site/site.xml to update the version number. Then

mvn site-deploy 

Open the locally-generated website in your browser and check it looks OK. When you are happy
with it, type 

cp -r /tmp/ production/ 

and commit the changes. The updated website will be published to immediately
(it uses [svnpubsub|]). 

=  Announce the Release =

TODO: Add a news section to the website. 

Send an email to (the from: address must be E.g. 

Subject: [ANNOUNCE] Apache Blur 0.1.0 released 

The Apache Blur team is pleased to announce the release of Blur 0.1.0. 

This is the first release of Apache Blur, a set of libraries for 
running cloud services such as Apache Hadoop, HBase, ZooKeeper, and 

The release is available here: 

The full change log is available here: 

We welcome your help and feedback. For more information on how to 
report problems, and to get involved, visit the project website at 

The Apache Blur Team 

View raw message