TG Releases - fieldenms/tg GitHub Wiki

TG Releases

This page covers the details of how to perform TG releases and the reasoning behind version increases.

  1. TG Releases and Versions Plugin
  2. Determining a release version

TG Releases and Versions Plugin

Releasing of TG follows a gitflow workflow with minor deviation from the naming conventions for branches. However, instead of utilising the git's gitflow extension library and Maven's release plugin, there is bash script tg-release.sh. This script uses Maven's versions plugin for updating module versions and implements the release steps according to the gitflow workflow.

The script requires 4 parameters:

  1. A release version. For example, 1.4.6. Recommendations for determining the version are given below.
  2. The next development version. For example, 1.4.7-SNAPSHOT. The suggested approach is to increase the PATCH part by 1 and add -SNAPSHOT.
  3. A value for parameter databaseUri.prefix. For example, //localhost:5432/ci_.
  4. A value for parameter fork.count. For example, 4.

Here is an example of how release 1.4.6 was performed.

./tg-release.sh '1.4.6' '1.4.7-SNAPSHOT' '//localhost:5432/ci_' 4

Note: In order to perform TG releases, the user should have the git push rights for branches develop and master.

Determining a release version

For a given release, its version number should be determined based on the scope and impact of changes implemented since the last release and should generally follow the recommendations for semantic versioning.

Additionally, the following rules should be consulted:

  • Increment the MINOR version when you add functionality in a backward compatible manner AND only the platform version needs to be changed in end-applications during upgrade. Otherwise, increment the MAJOR version.

    For example, adding new functionality that requires a dependency of the platform (e.g., Guice) to be upgraded necessitates a MAJOR release, because upgrading end-applications may require changing not only the platform version, but also the corresponding dependency version. For consistency, this rule should be followed even if it is known that no end-applications explicitly declare the dependency of the platform whose version changed (e.g., Guice).