Skip to content

Preparing for a Release

Ben Dalling edited this page Oct 23, 2016 · 19 revisions

Pre-Release Preparation

IMPORTANT: The version of the release should strictly follow the SemVer Specification (http://semver.org/spec/v2.0.0.html).

  • Create a branch that will have acceptance tests run against it. This will be named after the issue number that was raised to track the release and the name of the release. For example release/42/v1.2.3.

  • Ensure all tests pass as expected. Merge all relevant branches onto the release branch. To find out which branches require to be merged in, run the following:

    git branch -a --no-merged

    Pushing this branch back to GitHub will kick off the rspec tests. Check the results at:

    Assuming that these complete successfully, complete the beaker tests against all supported operating systems. These tests take a long time to complete so they should be a final step in the testing process.

    for node in $( rake beaker_nodes ); do
      BEAKER_set=$node BEAKER_destroy=onpass rake beaker || break
    done
  • Switch to the master branch and merge the release branch onto it.

  • Update the CHANGELOG. A suitable template for the change could be:

     ##YYYY-MM-DD - Release X.Y.Z ([diff](https://github.com/locp/cassandra/compare/1.5.0...X.Y.Z))
    
     ### Summary
    
     A short summary of what has been changed in this release.
    
     ### Features
    
     * N/A
    
     ### Bugfixes
    
     * N/A
    
     ### Improvements
    
     * N/A
    

    If required, update the copyright notice (see https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html).

  • Edit the metadata with the new release number with one of the following:

    rake module:bump:major # Bump module version to the next MAJOR version
    rake module:bump:minor # Bump module version to the next MINOR version
    rake module:bump:patch # Bump module version to the next PATCH version

    The commit comment for the checking of metadata.json should simply be the version number (e.g. v1.2.3).

  • Create a tag of the version number using:

    rake module:tag
    git push
    git push --tags
  • Run the following:

    rake module:clean
    rake build
    rake module:push

A suitable template for an issue to be raised to track the steps required to complete a release could be:

# Release Preparation
- [ ] A branch has been created for the release (e.g. release/42/v1.2.3)
- [ ] All branches have been merged onto the release branch.
- [ ] All spec tests are passing as expected.
- [ ] All beaker tests are passing as expected.
  - [ ] rake beaker:aws_centos6
  - [ ] rake beaker:aws_centos7
  - [ ] rake beaker:aws_debian8
  - [ ] rake beaker:aws_ubuntu12
  - [ ] rake beaker:aws_ubuntu14
  - [ ] rake beaker:aws_ubuntu16
  - [ ] rake beaker:circle_debian7

# Release Build and Upload (master branch)
- [ ] Merge the release branch onto the master.
- [ ] Contributors of pull requests have been acknowledged.
- [ ] The change log has been updated (on the changelog branch if supporting legacy branches).
- [ ] The metadata has been updated.
- [ ] A tag has been created branch (automatically done).
- [ ] The package has been built and uploaded to Puppet Forge branch (automatically done).

# Post Release
- [ ] The milestone associated with the release has been closed.
- [ ] Master branch has been merged onto `release/latest` branch (automatically done).
- [ ] All branches associated with issues closed down in the release have been deleted.
- [ ] A message has been posted to https://gitter.im/locp/cassandra
Clone this wiki locally