Answers: <p>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).</p>
  <p>Here is the idea -</p>
  <ul>
  <li>You create your project in Reliza Hub and choose versioning schema, i.e. semver.</li>
  <li>You may also choose custom schema for feature branches (default is Branch.Micro).</li>
  <li>Next, you generate a project token from Reliza Hub and set it to your
  CI system.</li>
  <li>Then inside your CI, add a retrieve version step, which would call Reliza Hub for the next version. See samples of this on GitHub - <a href="https://github.com/relizaio/reliza-hub-integrations" rel="nofollow noreferrer">https://github.com/relizaio/reliza-hub-integrations</a> (note that for Jenkins there is now a dedicated plugin).</li>
  </ul>
  <p>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.</p>
  <p>If you want to adopt automatic increments of major version component - versus minor component - versus patch component, use Conventional Commits - <a href="https://www.conventionalcommits.org/en/v1.0.0/" rel="nofollow noreferrer">https://www.conventionalcommits.org/en/v1.0.0/</a></p>
  <p>Basically, if you start your commit message with <em>fix</em>, it would know to increment patch; if you start it with <em>feat</em>, it would know to increment minor.</p>
  <p>You can also put what's called <em>Version Pin</em> on a specific branch - i.e. you can set it to <em>1.3.Micro</em> - then regardless of anything else, inside this branch version will only be incremented within Major 1 and Minor 3.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-07-19T12:56:31.130Z
Answers: Just curios, what is your recommendation regarding branching strategy? (it's used due to corporate standards)
Answers: Ievgen
Answers: CC BY-SA 4.0
Answers: 2021-07-19T13:09:08.793Z
Answers: Trunk Based Development - https://trunkbaseddevelopment.com/
Answers: taleodor
Answers: CC BY-SA 4.0
Answers: 2021-07-19T13:32:08.477Z
Answers: 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 :)
Answers: Ievgen
Answers: CC BY-SA 4.0
Answers: 2021-07-19T17:53:34.460Z
Answers: Actually, you don't have to compromise on quality - but yes, it's out of scope of the conversation ;)
Answers: taleodor
Answers: CC BY-SA 4.0
Answers: 2021-07-19T10:15:07.933Z
Answers: 2021-07-19T10:15:07.933Z
Answers: taleodor
Body: <p>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).</p>
  <p>Version currently stored as the part of the code and depends on the project language:
  (ex: JavaScript it's package.json)</p>
  <p>Version suppose to be used for:</p>
  <ul>
  <li>Docker image tag</li>
  <li>Package/code/library bundle</li>
  <li>Displayed to the user and added to the release notes.</li>
  </ul>
  <p><a href="https://i.sstatic.net/5jmlb.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/5jmlb.png" alt="enter image description here" /></a></p>
  <p>I am having a few strategies in mind</p>
  <p><strong>Scenario 1</strong></p>
  <ul>
  <li>Add checklist template to the merge request so reviewer has to mark checbox that version was increased.</li>
  <li>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?</li>
  </ul>
  <p><strong>Scenario 2</strong></p>
  <ul>
  <li>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)</li>
  </ul>
  <p>I would appreciate any suggestions and your ideas.
  BR</p>
  
Tags: <gitlab><python><versioning><javascript>
Title: GitLab Maintain versions of the code in GitLab CI/CD pipeline for the develop branch
UserDisplayName: Ievgen
ThreadText: # GitLab Maintain versions of the code in GitLab CI/CD pipeline for the develop branch
  
  (Asked by: username_0 on 2021-07-16)
  
  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](https://i.sstatic.net/5jmlb.png)](https://i.sstatic.net/5jmlb.png)
  
  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
  
  **Tags:** gitlab, python, versioning, javascript
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-07-19. Score: 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.
  
  > **Comments:**
  > **username_0**: Just curios, what is your recommendation regarding branching strategy? (it's used due to corporate standards)  
  > **username_1**: Trunk Based Development - https://trunkbaseddevelopment.com/  
  > **username_0**: 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 :)  
  > **username_1**: Actually, you don't have to compromise on quality - but yes, it's out of scope of the conversation ;)  
  
  ---
  
  