Release Plan

EvoAl uses continuous integration and delivery to create nightly builds and releases. Based on the state of the release branch, an official release is produced every six months (in April and October), and its version numbers will be YYYY.MM.VV, e.g. 2024.10.0 or 2025.3.0.

Versioning Strategy

The git graph below shows an overview of the fundamental CI/CD process. The repository has two main branches (release and develop) and several feature branches.

%%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'release'}} }%%
gitGraph
  commit id: "2024.3.0"
  branch develop
  checkout develop
  commit id: "2024.10.0-alpha.2"
  branch feature1
  checkout feature1
  commit id: "2024.10.0-alpha.3"
  commit id: "2024.10.0-alpha.4"

  checkout develop
  merge feature1
  commit id: "2024.10.0-alpha.5"

  branch feature2
  checkout feature2
  commit id: "2024.10.0-alpha.6"
  commit id: "2024.10.0-alpha.7"

  checkout develop
  merge feature2
  commit id: "2024.10.0-alpha.8"

  checkout release
  merge develop
  commit id: "2024.10.0-alpha.9"

  checkout develop
  branch feature3
  checkout feature3
  commit id: "2024.10.0-alpha.10"

  checkout develop
  merge feature3
  commit id: "2024.10.0-alpha.11"

  checkout release
  merge develop
  commit id: "2024.10.0-alpha.12"

  commit id: "2024.10.0-alpha.13" tag: "2024.10.0"
  checkout develop
  commit id: "2025-03.0-alpha.14"

feature- Branches

The actual development takes place in feature branches, which correspond to an issue each. Every change committed to a feature branch is automatically compiled by the CI and tested using the existing unit tests. When the feature is complete, a merge request against the develop branch is created to merge the feature into the develop branch.

Merge Request to develop

The merge request should be configured with the following settings:

1. Delete source branch when merge request is accepted
2. Squash commits when merge request is accepted

During the merge process, all existing unit and integration tests have to pass. Thus, it might happen that a feature branch that compiles correctly cannot be integrated due to a broken integration test. In such a case, the feature branch has to be fixed accordingly to allow a successful merge.

develop Branch

The develop branch is the integration area that continuously integrates features when their implementation is finished. The branch passes the unit and integration tests.

Merge Request to release

The develop branch is automatically merged into the release branch using an automated script. The merge request should be configured with the following settings:

1. Do not delete source branch when merge request is accepted
2. Do not squash commits when merge request is accepted
3. Auto merge on success

During the merge process, unit, integration, and regression tests are executed, and the code coverage is measured.

Release Branch

The release branch is comparable to nightly build versions that were successfully tested using all existing tests.

Official Release

We create an official release by creating a tag with the release version. Then, the build process is triggered, and a release is created and registered in GitLab.

Version Numbering

The version number of a release is given by the pattern YYYY-MM, e.g. 2024.03. After creating a release, we have to switch to the next release version number in the repository to, e.g. 2024.10.0.$CI_PIPELINE_IID. The part -alpha-$CI_PIPELINE_IID is for maven smaller than the final version 2024.10.0, thus making the maven repository magic work. The variable $CI_PIPELINE_IID is set by GitLab automatically and corresponds to a project-specific increasing build number.

The version number is stored in two places, and we have to adapt both locations for and after a release:

• .gitlab-ci.yml: Here, we construct the version number based on the CI pipeline variable.
• **/.mvn/maven.config: Here, we have a hardcoded version for manual build on the developer's machines. It is set to a large value (to be larger than the CI build number).

Within a release cycle, we first switch to an -alpha version. It is possible that we add additional intermediate "versions" if we want to add additional build milestones. The order would be:

• alpha
• beta
• milestone
• rc
• snapshot