This page describes how to make a release of Apache Bigtop (incubating). Most of the content is shamelessly stolen from the the Whirr release process – thanks Whirr team!

0. Before you begin.

Apache Bigtop (incubating) is following a predictable "train model" of releases popularized by the Ubuntu Linux. Currently releases happen every quarter. A release of Bigtop is a culmination of a quarter of development activities and also a testament to the particular state of the Hadoop ecosystem at the time. IOW, what are the most cutting edge versions of the components that still work together as an integrated system.

Scrubbing the JIRA.

3-4 weeks before a committed release date a All release activities are coordinated by a volunteer release manager (RM) for a given release is supposed to start a process of scrubbing the JIRAs. This involves:

1. taking care of all the patch available issues for a given release

...

who is chosen during the release planning. If you happen to be a first time RM here's what you need to do in order to be able to carry out the mechnics of the release

1. Generate PGP code signing keys
2. Ensure that your PGP signing keys are available in: httphttps://svn.apache.org/repos/asf/incubator/whirrbigtop/dist/KEYS^{Image Modified} More details can be found here.
3. Copy the new KEYS file to the release folder /www/www.apache.org/dist/incubator/whirr bigtop on people.apache.org

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.

...

Ensure that you have setup your ssh keys on people.apache.org, 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)

Done with the above? Proceed with the rest of the steps:

1. Scrubbing the JIRA.

3-4 weeks before a committed release date a release manager (RM) for a given release is supposed to start a process of scrubbing the JIRAs. This involves:

1. taking care of all the patch available issues for a given release
2. send an email to the bigtop-dev mailing list reminding the community of the upcoming release and asking them to spend 2-3 days raising the priority of the "must fix" issues for a given release to a "Blocker" status AND making sure that Fix Versions field is set to an upcoming release. Of course, it goes without saying that people have to volunteer to work on this issues – this is not an exercise of assigning work to others.
3. after waiting for 2-3 days for community to respond and for the Blockers to settle down – make sure that the resulting list looks reasonable and that there is a general expectation that the release can happen given the state of the source base.

Create a Release Series Branch

...