Release Process after R18.3

Lifecycle

• release begins
• features are developed in feature branches
  • dev, int and pro branches should be protected so that one is forced to use feature branches and merging
• finished features are merged to the dev branch (and int / pro if needed)
• the int branch is only needed, if the artifact is actively used in the Integration test system, if this is not the case, you can skip all instructions to int and directly merge from dev to pro
• cutoff date: the date where the current release is finalized
  • all projects have to have an up to date pro branch
  • all pro branches have to compile and have to be tested by developers
  • each artifact is released
• release has been finished

Version numbers

The version of each project will be set to represent the current release, e.g. 19.0.0-SNAPSHOT for a dev version, 19.0.0-RC-INT-SNAPSHOT for the integration version and 18.3.0 for the release version of pro.

The major version represents the Release version.
The minor version is a counter for each intermediate release (complete software stack release including merged (API) changes from newly developed features).
The tiny version represents the bugfix releases (single project).

General Scenario

Assume the following situation: Relese 18.3 has just been finished and is already released in version 18.3.x; features for Release 18.4 are currently developed.

• all versions in dev are 19.0.0-SNAPSHOT
• all versions in int are 19.0.0-RC-INT-SNAPSHOT
• all versions in pro are 18.3.1-SNAPSHOT (in preparation for a bugfix)

In the rare case, that a bug had happened and was reported, it has to be fixed in a bugfix branch and has to be merged to dev, int and pro branches. The pro branch will then be re released in version 18.3.1.

In the case, that it is decided to do an intermediate release, all needed feature branches are merged to dev (no general ACO-Artifact version updates!). The dev branch is then merged to the int branch. This stack can then be tested in the integration environment before it gets merged to the pro branch in version 18.4.0.

• after an intermediate release all versions in pro branch are 18.4.1-SNAPSHOT (in preparation for a bugfix)

At the latest of the cutoff date, each project is branched from dev to int (with version number 19.0.0-RC-INT-SNAPSHOT). After int has been tested it can be merged to the pro branch (with version number 18.4.0-SNAPSHOT). The pro branches are now released in version 19.0.0, tagged and published to the nexus, also the pro branch has now the version 19.0.1-SNAPSHOT. The dev branch of each project is updated to 20.0.0-SNAPSHOT, int respectively is updated to 20.0.0-RC-INT-SNAPSHOT, and have to be SNAPSHOT deployed again.

This means:

• versions:
  • in the dev and int branches there are never release versions
  • in pro branch
    • before the release: there are only SNAPSHOT version of the to be released version (x.y.0-SNAPSHOT)
    • after release: there are only SNAPSHOT versions for the next bugfix (x'.y'.1-SNAPSHOT)
      • dependency versions are fixed (x'.y'.0)
• developing
  • the developing of features occurs only in feature branches
  • bugfixes are resolved in bugfix branches and merged back to dev, int and release branches
    
    • bugfixes are only released from the pro branch in the next bugfix version (e.g. 18.3.1 for the first bugfix in R18.3)
  • dev should be merged to int
    • if needed, a changed dev branch state can be merged to int again
  • int should be merged to pro only once (until the cutoff date, afterwards it is forbidden)
    • if needed, a changed int branch state can be merged to pro again (until the cutoff date, afterwards it is forbidden)
• deployment
  • SNAPSHOTs are only deployed from dev branch
  • RC-INT-SNAPSHOTS are only deployed form int branch
  • releases are only released from release branches

Release process for developers

• before cutoff date:
  • develop features as usual in feature branches
  • merge features to dev once they are finished
  • follow preparation steps described here, optionally create SNAPSHOT deploys
  • merge project dev to int / int to pro
• after cutoff date:
  • do a git pull to receive the latest version definitions in the pom.xml that were updated during the reactor release process

Release itself (done by release engineer) / reactor release

Please see AppHowToRelease .

Release as Graphic