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