Release Process after R16

Lifecycle

• release begins
• features are developed in feature branches
  • master, int and release branches should be protected so that one is forced to use feature branches and merging
• finished features are merged to the master branch
• cutoff date: the date where the current release is finalized
  • all projects have to have a release branch
  • all release 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 changed to represent the current release, e.g. 17.0.0-SNAPSHOT for a SNAPSHOT version, 17.0.0-RC-INT-SNAPSHOT for the integration version or 17.0.0 for the release version of R17.

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

General Scenario

Assume the following situation: R17 has just been finished and is already released in version 17.0.0; features for R18 are currently developed.

• all versions in master are 18.0.0-SNAPSHOT
• all versions in R17 branches are 17.0.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 master and in the current release branch. The R17 branch will then be re released in version 17.0.1.

In the case, that it is decided to do an intermediate release, all needed feature branches are merged to R17 (no general ACO-Artifact version updates!). The R17 branch is then released in version 17.1.0.

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

At the latest of the cutoff date, each project is branched from master to R18 (with version number 18.0.0-SNAPSHOT). R18 branches are now released in version 18.0.0, tagged and published to the nexus, also the R18 branch has now the version 18.0.1-SNAPSHOT. Now the master branch of each project has to be updated to 19.0.0-SNAPSHOT and have to be SNAPSHOT deployed again.

This means:

• versions:
  • in the master branch there are never release versions
  • in release branches
    • before the release: there are only SNAPSHOT version of the to be released version (x.y.z-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 master, int and release branches
    
    • bugfixes are only released from the release branch in the next bugfix version (e.g. 18.0.1 for the first bugfix in R18)
  • the master should be branched to the next release branch only once (until the cutoff date, afterwards it is forbidden)
    • if the branch already exists, the mvn release:branch command will throw an error, in this case you have to revert and merge manually
    • if needed, a changed master branch state can be merged to the next release branch again (until the cutoff date, afterwards it is forbidden)
• deployment
  • SNAPSHOTs are only deployed from master 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 master once they are finished
  • follow preparation steps described here, optionally create SNAPSHOT deploys
  • publish project to the next release branch based on the next release version
    • mvn release:branch -DupdateWorkingCopyVersions=false -DbranchName=Rx
      • where x is the release name
      • e.g. mvn release:branch -DupdateWorkingCopyVersions=false -DbranchName=R18
• after cutoff date:
  • do a git pull to receive the newest version definitions in the pom.xml that were updated during the reactor release process

Release itself (done by release engineer) / reactor release

The release itself can now be done by a single person.

The release is done on the release branches created by the developers

• the projects are released in the reactor build order (a script is provided to check out each release branch and use the reactor to release them)
• parent and dependency versions of all projects have to be updated to Rx.y.0-SNAPSHOT
• Commit and push to Git if changes have been performed to the POM while updating parent and dependencies.
• in general the same process as before (without the preparation steps), see here, in short:
  
  • mvn clean install
    • build the latest SNAPSHOT version to test if all artifacts compile together
  • mvn release:prepare -DreleaseVersion=17.0.0 -DdevelopmentVersion=17.0.1-SNAPSHOT
    • use the current release version for each dependency (e.g. x.y.0) for the release and the next development iteration
    • use the next tiny snapshot version for your own artifact (e.g. x.y.1-SNAPSHOT)
    • the tag for the current release will be created
  • mvn release:perform
    • the tag is checked out, build and published to the nexus
• update master to the next development version (each project with its dependencies)
  
  • Next version is always <x+1>.0.0-SNAPSHOT
  • commit and push to Git

Release as Graphic

            +
            |      develop features in separate branches and merge to master when finished
            |  +---------------+                               +---------------+
     master |  |17.0.0-SNAPSHOT|----------------------------+->|18.0.0-SNAPSHOT|---------------+->
            |  +---------------+                            ^  +---------------+               |
            |          | SNAPSHOT deploy           increase | version and SNAPSHOT deploy      | optional Intermediate release
+----------------------------------------------------------------------------------------------+----------------------------------------------+
            |          | branching                          |                                  | merge without version update
            |          |           +---------------+     +------+         +---------------+    |         +------+         +---------------+
 R17 branch |          +---------->|17.0.0-SNAPSHOT|---->|17.0.0|-------->|17.0.1-SNAPSHOT|----+-------->|17.1.0|-------->|17.1.1-SNAPSHOT|
            |                      +---------------+     +------+         +---------------+              +------+         +---------------+
            |                                               | release                                       | release
+---------------------------------------------------------------------------------------------------------------------------------------------+
            |                                               |                                               |
            |                                               |    +------+                                   |    +------+
        tag |                                               +--->|17.0.0|                                   +--->|17.1.0|
            |                                                    +------+                                        +------+
            +