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 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:
x.y
branch, named something like x.y.z'-RCN
.x.y.z'
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 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:
x.y
branch, named something like x.y.0-RCN
.x.y.0
x.y.0-RCN
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.
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.
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.
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.
For the sake of clarity, some examples of common situations are included below.
Branch from master
to 1.6
git checkout master && git branch 1.6
Tag 1.6.0-RC1
from the just created 1.6
branch
git 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 from 1.6.0
git checkout master && git merge 1.6
Update the project version in master
to 1.7.0-SNAPSHOT
[making]: {{ site.baseurl }}/contributor/making-release