Release instructions (for committers)

Eclipse Collections project follows Semantic Versioning, as described in the guidelines for contributing. You should not need to change version numbers in pom files. This is taken care of by Hudson release build.

The release workflow involves running 3 Hudson builds.

Regular release from master

Hudson Build: release

Parameters

NEW_VERSION: The version number for this release, e.g. 7.0.0, 7.1.0

This build will invoke the steps below internally (assuming NEW_VERSION is 7.1.0).

1. Clone master from GitHub.
2. Update version number in the pom files, e.g. from 7.1.0-SNAPSHOT to 7.1.0.
3. Commit and push the version number changes to master.
4. Tag the previous commit, e.g. annotated tag 7.1.0.
5. Invoke deploy build for the new tag.

Service (patch) release from branch

Hudson Build: service-release

Parameters

NEW_VERSION: The version number for this release, e.g. 7.0.1, 7.0.2

SERVICE_RELEASE_BRANCH: The name of the branch for the current service release, e.g. 7.0.x

This build will invoke the steps below internally (assuming NEW_VERSION is 7.0.1 and SERVICE_RELEASE_BRANCH is 7.0.x).

1. Clone branch from GitHub, e.g. 7.0.x.
2. Update version number in the pom files, e.g. from 7.0.1-SNAPSHOT to 7.0.1.
3. Commit and push the version number changes to branch, e.g. 7.0.x.
4. Tag the previous commit, e.g. annotated tag 7.0.1.
5. Invoke deploy build for the new tag.

Start a new release version development (a.k.a. SNAPSHOT version)

Hudson Build: new-version

Parameters:

NEXT_VERSION: The planned next release version number, e.g. 7.1.0, 8.0.0. No need to add -SNAPSHOT which is appended by the job automatically.

RELEASE_BRANCH: Default is master. Use a branch name for service releases, e.g. 7.1.x, 8.0.x.

This build will invoke the steps below internally (assuming NEW_VERSION is 8.0.0).

1. Clone master from GitHub.
2. Update version number in the pom files, e.g. from 7.1.0 to 8.0.0-SNAPSHOT.
3. Commit and push the version number changes to master.