<pathd="M 60 60 L 300 60 L 320 135 L 300 210 L 60 210 L 80 135 Z"fill="#e6e6e6"stroke="#808080"stroke-width="3"stroke-miterlimit="10"pointer-events="all"/>
<pathd="M 1.25 60 L 60 60 L 80 135 L 60 210 L 1.25 210 L 21.25 135 Z"fill="#3399ff"stroke="#808080"stroke-width="3"stroke-miterlimit="10"pointer-events="all"/>
<pathd="M 378.75 60 L 580 60 L 600 135 L 580 210 L 378.75 210 L 398.75 135 Z"fill="#e6e6e6"stroke="#808080"stroke-width="3"stroke-miterlimit="10"pointer-events="all"/>
<pathd="M 320 60 L 378.75 60 L 398.75 135 L 378.75 210 L 320 210 L 340 135 Z"fill="#3399ff"stroke="#808080"stroke-width="3"stroke-miterlimit="10"pointer-events="all"/>
@@ -130,7 +130,7 @@ But a **publish** is not necessarily related to a **release**. Depending on the
### Release
Functionally, a **release** involves the following steps:
Functionally, a **release** involves the following:
1.`[mandatory]` determine the next release **version** (either manually or automatically),
2.`[optional]`**bump version**
@@ -141,11 +141,15 @@ Functionally, a **release** involves the following steps:
4.`[optional]` create a [GitLab release](https://docs.gitlab.com/ee/user/project/releases/),
5.`[mandatory]`**package** the code (language-dependent format) & **publish** the versioned package(s) to an appropriate repository.
Some _to be continuous_ templates provide their own release job when supported by the build tool (ex: Maven with the [Maven Release Plugin](https://maven.apache.org/maven-release/maven-release-plugin/), Python with [Bumpversion](https://pypi.org/project/bumpversion/) or with the [Poetry Version](https://python-poetry.org/docs/cli/#version) command), but the release action can also be implemented by a separate tool/template such as [semantic-release](https://semantic-release.gitbook.io/semantic-release/) that can gracefully automates the release process (automatically determines the next version number based on Git commit messages, enforces [semantic versioning](https://semver.org/), generates the release notes, creates the tag and the GitLab release).
In _to be continuous_, it is implemented in two separate stages:

Some _to be continuous_ templates provide their own release stage 1 job implementation (_Prepare_) when supported by the build tool (ex: Maven with the [Maven Release Plugin](https://maven.apache.org/maven-release/maven-release-plugin/), Python with [Bumpversion](https://pypi.org/project/bumpversion/) or with the [Poetry Version](https://python-poetry.org/docs/cli/#version) command), but the release _Prepare_ can also be implemented by a separate tool/template such as [semantic-release](https://semantic-release.gitbook.io/semantic-release/) that can gracefully automates the release process (automatically determines the next version number based on Git commit messages, enforces [semantic versioning](https://semver.org/), generates the release notes, creates the tag and the GitLab release).
### Publish
As explained before, publishing a code package is not necessarily related to a release process (as some technologies - such as Maven - allow publishing _unstable_ package versions) but a release should always end by publishing the versioned packages.
As explained before, publishing a code package is not necessarily related to a release process (as some technologies - such as Maven - allow publishing _unstable_ package versions) but a release always ends by publishing the versioned packages (stage 2 _Perform_ hereabove).
As a result, all publish-capable templates are fully compatible with `semantic-release` or any alternative implementing the release process.