Release Howto

This page describes how to release a new version of elephant-bird.

Merge desired changes to master

All releases are created off the master branch, so merge any changes and push them to master. When making changes to master its typically better to submit a pull request rather than changing directly since that creates an issue to reference the discussion around the change.

Update milestone issues

Each issue merged to master should be assigned to the release milestone.

Create the new release artifacts

• Update the version number in build.xml
• ant -Dtest.library.path=/path/to/native/lzo/libs clean test publish

This does a clean build, runs test, and publishes the artifacts to the internal maven repo. The artifacts are not committed yet. Setting test.library.path ensures that lzo tests run.

Update documentation

Update the following files for each release:

• Readme.md - update documentation for major changes users should be aware of
• Changes.md - update with specific changes in this release

Publish the release

Push the release as a new branch, and send a pull request to make it live. Unless there's a very good reason someone else should merge the release, just to make sure everything looks good before it goes live.

Tag the release

Github has a fancy feature that allows users to download a zip file for a given tag. This feature is used to allow users to download the sources for a given release. To tag release:

$ git pull        # make sure you are the the release commit
$ git tag -a v2.2.1 -m 'version 2.2.1'
$ git tag         # make sure you don't have any of your personal tags
$ git push --tags # pushes the tags to origin

Update the version to SNAPSHOT

After releasing, bump the version number and add "-SNAPSHOT" so people building from trunk know they're not building an official release.

Announce the release on the mailing list

Let people know about the release! Ping [email protected] with an announcement about the release so people know to upgrade.