Have a documented release process (for v5+)
...including what to do on CHANGELOG, Release notes, Gitlab Release and (maybe automated) deployment
TODO list to create a release
- Update CHANGELOG
- Create a release note
- Create the actual technical release (with its git tag + gitlab package + gitlab release)
- communicate on the forum (and if major version on LinuxFR)
See Management for Asqatasun v5 for a real-life example
Creating a release: ideas
- Version is defined by a human, we do not want automatic stuff to determine version number
- We need to distinguish Package from Tag from Relase
- A Package is a build artefact stored with Gitlab Generic Package. A Package is created at each successful merge request in Master. It can be a versioned package (
5.0.0-beta.2
) or a snapshot package (5-SNAPSHOT
). - A Tag is a git tag, that is placed on the branch Master
- A Release is the technical object Gitlab Release
- A Package is a build artefact stored with Gitlab Generic Package. A Package is created at each successful merge request in Master. It can be a versioned package (
Imagined workflow:
- A human sets a new version in the POMs (with
mvn versions:set
? withmvn release:prepare
?) on a feature branch - Once merged in master, a git tag is created (automatically ?), a gitlab package is created and a gitlab release is also created
- As a post operation, the next version is set in the POMs
Resources > Gitlab-CI related
- Gitlab Guided Explorations Write CI-CD Variables in Pipeline For Generic Package Version Management
- Gitlab-CI doc: create a release directly from the GitLab CI pipeline
- Gitlab Doc >
release-cli
example: Release assets as Generic packages
Resources > Maven (or similar tools)
-
Maven Release plugin offering command
mvn release:prepare
- This plugin is developer-oriented, not adapted to run in a CI. Example of action: "Check that there are no uncommitted changes in the sources"
- Moreover, I couldn't find how to separate the action of setting the "finale" version from the one of setting the new "-SNAPSHOT" version. In the CI, we need to have this split into two different parts because we need between them to build dans upload the artifacts.
-
Maven Versions plugin offering command
mvn version:set
- How to run Maven Release on GitLab with Artifactory Recent (2021-03-24) and complete.
- Maven release plugin with GitLab CI Pipeline Recent (2020-12-28) and educational.
-
Creating a release with GitLab CI and Composer (2020-10-07) An interesting comparison point, with its real
gitlab-ci.yml
file - Gitlab Forum: Getting mvn:release to work with Gitlab CI
Semver vs Maven versioning
See Asqatasun Doc: DEV Doc: managing semver vs Maven versioning (including -SNAPSHOT)
Edited by Matthieu FAURE