Release Management
Releases, although not a day to day task, have their own unique steps which are to be followed. Releases can be categorized in to minor and major releases
A minor release
A minor release is some set of changes z'
on top of a version x.y.z
.
Typically, z'
is simply z + 1
, e.g. given a release named ‘1.6.0’, and the
next minor release is ‘1.6.1’. These changes for z'
should not break any
client code which works against z
and should absolutely not change the public
API.
By convention, the branch containing the changes z'
should be named
x.y
(where the changes for z'
are commits since x.y.z
. The steps to take are as follows:
- Make a release candidate
- Create a branch for the release candidate from the
x.y
branch, named something likex.y.z'-RCN
. - Test and Vote
- Create a GPG-signed tag with the correct final name:
x.y.z'
- Push a delete of the remote branch
x.y.z'-RCN
This process is not firm and should not be viewed as requirements for making a release. The release manager is encouraged to make use branches/tags in whichever way is best.
A major release
A major release is a release in which multiple new features are introduced
and/or the public API are modified. The major release y'
, even when the
client API is not modified, will typically contain many new features and
functionality above the last release series y
. A major release also resets
the z
value back to 0
.
The steps to create a new major release are very similar to a minor release:
- Make a release candidate
- Create a tag of the release candidate from the
x.y
branch, named something likex.y.0-RCN
. - Test and Vote
- Create a GPG-signed tag with the correct final name:
x.y.0
- Push a delete of the remote branch
x.y.0-RCN
The infrastructure
This section deals with the changes that must be requested through INFRA. As with any substantial INFRA request, the VOTE and result from the mailing should be referenced so INFRA knows that the request has been acknowledged. Likely, a PMC member should be the one to submit the request.
Repositories
I believe that we will need multiple repositories to best align ourselves with how we currently track “Accumulo” projects. The repositories follow:
-
The main source tree. This will track the standard trunk, branches, tags structure from Subversion for Apache Accumulo.
-
One repository for every project in contrib: Accumulo-BSP, Instamo Archetype, and the Wikisearch project. Each of these are considered disjoint from one another, and the main source tree, so they each deserve their own repository.
Given the list of repositories that currently exist on the ASF site and a brief search over INFRA tickets, multiple repositories for a single Apache project is not an issue. Having this list when making the initial ticket will likely reduce the amount of work necessary in opening multiple INFRA tickets.
Mirroring
It should be noted in the INFRA request that each repository will also need to be configured to properly mirror to the ASF Github account to provide the same functionality with current have via the git+svn mirror. Same change needs to be applied for the Apache hosted mirror’ing.
Mailing lists
It should be noted in the INFRA request that commit messages should be sent to commits@accumulo.apache.org. The subject can be decided on using the provided variables.
Examples
For the sake of clarity, some examples of common situations are included below.
Releasing 1.6.0
-
Branch from
master
to1.6
git checkout master && git branch 1.6
-
Tag
1.6.0-RC1
from the just created1.6
branchgit tag 1.6.0-RC1 1.6
-
Test, vote, etc. and tag from 1.6.0-RC1
git -s tag 1.6.0 1.6.0-RC1
-
Delete the RC tag, if desired.
git tag -d 1.6.0-RC1 && git push --delete origin 1.6.0-RC1
-
Ensure
master
contains all features and fixes from1.6.0
git checkout master && git merge 1.6
-
Update the project version in
master
to 1.7.0-SNAPSHOT