Release builds (for committers)

Release builds

As described in contribution guide, Eclipse Collections project follows Semantic Versioning. For each release, you should not need to touch version numbers in pom files manually. This is taken care of by Hudson release build.

Below are the 3 builds committers would run as part of release workflow.

Major/minor release

Hudson Build: release

Parameters

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

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

1. Checkout master branch from GitHub.
2. Update version# in pom files (e.g. from "7.1.0-SNAPSHOT" to "7.1.0").
3. Commit and push version# changes, create a tag "7.1.0".
4. Invoke deploy build for tag "7.1.0".

Service (patch) release

Hudson Build: service-release

Parameters:

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

SERVICE_RELEASE_BRANCH: Branch name for the current service release e.g. 7.0.x

This build will invoke the steps below internally (assuming NEW_VERSION="7.0.1", SERVICE_RELEASE_BRANCH="7.0.x").

1. Checkout branch "7.0.x" from GitHub.
2. Update version# in pom files (e.g. from "7.0.1-SNAPSHOT" to "7.0.1").
3. Commit and push version# changes to branch "7.0.x" with creating a tag "7.0.1".
4. Invoke deploy build for tag "7.0.1".

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

Hudson Build: new-version

Parameters:

NEXT_VERSION: Next release version#. e.g. 7.1.0, 8.0.0. No need to add -SNAPSHOT which is appended by the job automatically.

RELEASE_BRANCH: Default "master" for major/minor releases. Put branch name for service releases (e.g. 7.1.x, 8.0.x)

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

1. Checkout master branch from GitHub.
2. Update version# in pom files (e.g. from "7.1.0" to "8.0.0-SNAPSHOT").
3. Commit and push version# to master branch in GitHub.