Accumulo Release Guide

Accumulo works on a very simple cycle of major releases with the minor releases when needed. The intent is for all major features to be implemented in a major release, with only bug fixes and minor features being included in minor releases. API changes should intend to only be made on major releases, with continued support of previous API for at least one major revision. This will give user code a major revision to convert from the old API to the new API.

Accumulo works on a very simple cycle of major releases with the minor releases when needed. The intent is for all major features to be implemented in a major release, with only bug fixes and minor features being included in minor releases. API changes should only be made on major releases, with continued support of the previous API for at least one major revision. This will give user code a major revision to convert from the old API to the new API.

Note: There will be times where API compatibility cannot be maintained, which we understand. However, this should only be considered when there is NO other option.

Major Release

Vote to start the major release process- this should be in consensus with the community and should be discussed on the accumulo-dev mailing list before the next steps take place. The majority of the committers must +1 the vote and all -1s need to be discussed.
- Vote to start the major release process. This should be in consensus with the community and should be discussed on the accumulo-dev mailing list before the next steps take place. The majority of the committers must +1 the vote and all -1s need to be discussed.
  - There is not a strict time limit between major releases, but some consideration should be made because we don't want to give our early adopters version fatigue.
  - This will be the feature freeze for the version- Any features considered after this call need a very strong reason for implementation, which can be discussed via mailing list.
  - This will be the feature freeze for the version. Any features considered after this call need a very strong reason for implementation, which can be discussed via mailing list.
- Create a JIRA version for the proceeding release number- this is so we can begin the process of noting which features are bound for the current trunk vs. a future version.
- Handle all JIRA tickets assigned for the current major release version- all tickets who's version is changed should have an explanation of why they are not to be handled in the current release.
- Once all JIRA tickets against the codebase (documentation tickets do not count) are resolved/redirected, the code will be branched in SVN.
  - Create a JIRA version for the proceeding release number. This is so we can begin the process of noting which features are bound for the current trunk vs. a future version.
  - Handle all JIRA tickets assigned for the current major release version. Any ticket whose version is changed should have an explanation of why it is not to be handled in the current release.
  - Once all JIRA tickets against the codebase (except documentation tickets) are resolved/redirected, the code will be branched in SVN.
    - While there is currently a new trunk for the next release, it is highly discouraged to begin committing new features to it because this is when the current release is being tested. Any major bugs found will have to be patched in both versions and we want to make the process as seamless as possible.
    - New trunk needs to have it's version information updated.
    - The new trunk needs to have its version information updated.
  - Wrap up any standing documentation endeavors, whether or not there are tickets for them.

Accumulo Release Guide

Major Release

Minor Release

Testing

Releasing