I would like to ensure that code merged via merge request in a GitLab from the feature branch to our develop branch has always a new unique version (gitflow strategy).

Version currently stored as the part of the code and depends on the project language: (ex: JavaScript it's package.json)

Version suppose to be used for:

  • Docker image tag
  • Package/code/library bundle
  • Displayed to the user and added to the release notes.

enter image description here

I am having a few strategies in mind

Scenario 1

  • Add checklist template to the merge request so reviewer has to mark checbox that version was increased.
  • Additionally to the previous manual step I would like to have CI/CD step for the validation: Ex: need to check previous version of commit with a new one to ensure that pending merge request has greater version than previous. Any clues whether it's possible to determine?

Scenario 2

  • CI/CD on a develop branch should automatically increase version of the package and commit. Not sure whether this possible and whether ad-hoc commit will no trigger CI/CD again. (can a problem to handle hotfixes)

I would appreciate any suggestions and your ideas. BR

1 Answer 1


While I generally do not recommend GitFlow these days, fully automated way to do what you ask is possible to achieve with an external system. Below I will describe how to do it with Reliza Hub (which is the one I'm developing - but you may find other options).

Here is the idea -

  • You create your project in Reliza Hub and choose versioning schema, i.e. semver.
  • You may also choose custom schema for feature branches (default is Branch.Micro).
  • Next, you generate a project token from Reliza Hub and set it to your CI system.
  • Then inside your CI, add a retrieve version step, which would call Reliza Hub for the next version. See samples of this on GitHub - https://github.com/relizaio/reliza-hub-integrations (note that for Jenkins there is now a dedicated plugin).

After doing this, version will be auto-resolved on every run and every merge. In any case it is guaranteed that every version is unique and there are no conflicts between branches.

If you want to adopt automatic increments of major version component - versus minor component - versus patch component, use Conventional Commits - https://www.conventionalcommits.org/en/v1.0.0/

Basically, if you start your commit message with fix, it would know to increment patch; if you start it with feat, it would know to increment minor.

You can also put what's called Version Pin on a specific branch - i.e. you can set it to 1.3.Micro - then regardless of anything else, inside this branch version will only be incremented within Major 1 and Minor 3.

  • Just curios, what is your recommendation regarding branching strategy? (it's used due to corporate standards)
    – Ievgen
    Jul 19, 2021 at 12:56
  • Trunk Based Development - trunkbaseddevelopment.com
    – taleodor
    Jul 19, 2021 at 13:09
  • thanks for the link. I can imagine that trunk based approach are easier for the dev team and also can be applied when rapid development and releases are more important than strict quality (and some rules). I can see a lot of pitfalls but this is not a topic :)
    – Ievgen
    Jul 19, 2021 at 13:32
  • Actually, you don't have to compromise on quality - but yes, it's out of scope of the conversation ;)
    – taleodor
    Jul 19, 2021 at 17:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.