Release Process after R18

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
  • 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 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.2 has just been finished and is already released in version 18.2.x; features for Release 18.3 are currently developed.
  • all versions in master are 19.0.0-SNAPSHOT
  • all versions in R18_2 branches are 18.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 R18_2 branch will then be re released in version 18.2.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.3.0.
  • after an intermediate release all versions in pro branch are 18.3.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.3.0-SNAPSHOT). The pro branches are now released in version 18.3.0, tagged and published to the nexus, also the pro branch has now the version 18.3.1-SNAPSHOT. The dev branch of each project stays at 19.0.0-SNAPSHOT and have to be SNAPSHOT deployed again.

This means:
  • versions:
    • in the dev 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.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 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

Please see AppHowToRelease .

Release as Graphic

GIT_workflow.png

This topic: Applications > WebHome > AppHowToMain > AppHowToReleaseWithBranches
Topic revision: 06 Dec 2023, AndreasSchaller
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback