PR Checklist
### PR Structure
* [x] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
* [x] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
* [x] This PR's title starts with the jira ticket associated with the PR.
### Thoroughness
* [x] This PR adds tests for the most critical parts of the new functionality or fixes.
* [ ] I've updated the docs and the README with the added features, breaking changes, new instructions on how to use the repository.
### Release planning
* [x] I've decided if this PR requires a new major/minor/patch version accordingly to
[semver](https://semver.org/), and I've changed the name of the BRANCH to release/* , feature/* or patch/* .
What
This PR adds enhancements in two parts of the CI, in the version calculation and how to get the tags across the branches.
Why
In the old version of the CI, it was able to create new releases, functionalities and patches, but now it is able to pass from a patch version to a new release, or from a feature version to a release version.
Pratical examples:
how it used to work:
v0.0.30 -> v0.0.31 (new patch)
v1.0.0 -> v2.0.0 (new release)
v0.0.20 -> v0.1.20 (new feature)
With the enhancements it corrects the last behavior:
v0.0.20 -> v0.1.0 (a new feature, in this context, would be v0.1.0, not v0.1.20).
The way the code gets the latest tag changed to a better version, because existing code gets the latest tag in the branch. Now, the CI gets the latest tag across all branches (it diminishes the future chances of getting a bug).
Known limitations
A limitation that could be enhanced in the future is the way the code analyzes the prefix of the branch.
Now, it is release/ , patch/ , feature/ , but the user can come across with different ways of writing it: Release/ , Patch/ , Feature/
Adding pre-release versions: pre-alpha, alpha, beta types of versions.
PR Checklist
### PR Structure * [x] This PR has reasonably narrow scope (if not, break it down into smaller PRs). * [x] This PR avoids mixing refactoring changes with feature changes (split into two PRs otherwise). * [x] This PR's title starts with the jira ticket associated with the PR. ### Thoroughness * [x] This PR adds tests for the most critical parts of the new functionality or fixes. * [ ] I've updated the docs and the README with the added features, breaking changes, new instructions on how to use the repository. ### Release planning * [x] I've decided if this PR requires a new major/minor/patch version accordingly to [semver](https://semver.org/), and I've changed the name of the BRANCH to release/* , feature/* or patch/* .What
This PR adds enhancements in two parts of the CI, in the version calculation and how to get the tags across the branches.
Why
In the old version of the CI, it was able to create new releases, functionalities and patches, but now it is able to pass from a patch version to a new release, or from a feature version to a release version.
Pratical examples:
how it used to work: v0.0.30 -> v0.0.31 (new patch) v1.0.0 -> v2.0.0 (new release) v0.0.20 -> v0.1.20 (new feature)
With the enhancements it corrects the last behavior: v0.0.20 -> v0.1.0 (a new feature, in this context, would be v0.1.0, not v0.1.20).
The way the code gets the latest tag changed to a better version, because existing code gets the latest tag in the branch. Now, the CI gets the latest tag across all branches (it diminishes the future chances of getting a bug).
Known limitations
A limitation that could be enhanced in the future is the way the code analyzes the prefix of the branch. Now, it is release/ , patch/ , feature/ , but the user can come across with different ways of writing it: Release/ , Patch/ , Feature/ Adding pre-release versions: pre-alpha, alpha, beta types of versions.