Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Create a release branch

Current practice dictates that non-indie *.x branch pom versions must remain constant for the life of the branch. *.x branch pom files are versioned major version.minor version-SNAPSHOT (e.g., 2.8-SNAPSHOT). In addition, no snapshot jars are permitted in the Maven2 release repo. Because of these rules, particularly the latter, a release branch must be created prior to a release for each non-indie project in order to reset each pom <version> to a non-snapshot version (e.g., 2.8.1).

Release branches should only be created after all *.x branch blockers have been eliminated. Once the release branch is created the *.x branch is free to accept merged code not intended for the release. However, given the vagaries of CLE quality assurance late breaking release blockers are often discovered after the release branch is created. This creates challenges for the release team and branch managers since blocker fixes must be merged both to the *.x maintenance branch AND the release branch. Great vigilance is required to track the commit stream to ensure that fixes required for the release are not missed.

Indie projects, which leverage the Maven release plugin, are easier to manage. Releases are performed from existing *.x maintenance branches (no release branch is required) and the plugin handles pom version changes, tag creation and binaries generation and deployment automatically.

Non-indie Release branches are created using the following bash script.

TODO: add URL

The script takes six arguments.

No Format

$ bash sakaitagbuilder-2.8.bash [Jira ticket number] [source branch] [take HEAD=true|false] [target=branches|tags] [sakai version] [version suffix=mXX|aXX|bXX|rcXX]

$ bash sakaitagbuilder-2.8.bash SAK-20967 sakai-2.8.x true branches 2.8.1

...


Preparing the release branch for release

PROPERTIES SETTINGS (*.sakai.properties: default, demo, sample)

...