Answers: <p>I have a similar setup.</p>
  
  <p>For <code>feature/*</code> and <code>develop</code>, I use something like <code>18.08-SNAPSHOT</code> in my pom.
  When we're ready to start release hardening, I'll cut a release branch (<code>release/18.08</code>) and change the version in the pom/s to <code>18.08</code>.</p>
  
  <p>I'll also bump the version on develop to <code>18.09-SNAPSHOT</code>, for example.</p>
  
  <p>From there, bugfix and finalise the release, merge to <code>master</code> when appropriate.</p>
  
  <p>We're not properly CI/CD yet, but the issue I bumped in to with release builds was that I still needed unique builds in Artifactory.  So, at build time (for release branches) Jenkins will change the version in the pom to something like <code>18.08-326</code> (326 being build number).  It won't commit this change, but the artefact that gets built and pushed to Artifactory will be unique (<code>foobar-18.08-326.war</code>)</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-08-16T15:48:34.043Z
Answers: 2018-08-16T16:01:37.087Z
Answers: 2018-08-16T16:01:37.087Z
Answers: Denham Coote
Body: <p>I'm working on a Git workflow (not git-flow) for a Java project that uses Maven and Artifactory for artifact storage. On develop and feature/* branches the version number contains '-SNAPSHOT'. It is not desirable to have release/* or master branches with '-SNAPSHOT' so I'm trying to figure out when (and how) to get rid of it.</p>
  
  <p>I came up with a partial workflow, as below, but it doesn't handle removing 'SNAPSHOT':</p>
  
  <pre><code>                v1.0-snap    v1.0-snap
  feature/a       * ---------&gt; *
                  ^            |
                  |            |
                  |            v
  develop         *            * v1.0-snap
                  v1.0-snap    |
                               |
                               v        
  release/1.1        v1.0-snap * -----&gt; *
                                      v1.1-snap
  </code></pre>
  
  <p>I came up with 2 options, but both might be wrong.</p>
  
  <p><strong>Option 1</strong></p>
  
  <pre><code>                v1.0-snap    v1.0-snap
  feature/a       * ---------&gt; *
                  ^            |
                  |            |
                  |            v             v1.1-snap
  develop         *            * v1.0-snap  *
                  v1.0-snap    |           /
                               |          /
                               v         /
  release/1.1        v1.0-snap * -----&gt; * v1.1-snap
                                         \
                                          \
                                           \
  master                                    * --------&gt; *
                                            v1.1-snap   v1.1
  </code></pre>
  
  <p><strong>Option 2</strong></p>
  
  <pre><code>                v1.0-snap    v1.0-snap
  feature/a       * ---------&gt; *
                  ^            |
                  |            |
                  |            v             v1.1-snap
  develop         *            * v1.0-snap  *
                  v1.0-snap    |           /
                               |          /
                               v         /
  release/1.1        v1.0-snap * -----&gt; * ----- &gt;* v1.1
                                     v1.1-snap    \
                                                   \
                                                    \
  master                                             *
                                                    v1.1
  </code></pre>
  
  <p>Both options seems weird to me, though.</p>
  
  <p>Is there any best practice for this kind of flow?</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-08-19T21:54:45.133Z
Comments: How is the version mapped to the release/master branch?
Comments: gmolaire
Tags: <continuous-integration><git><maven>
Title: When to get rid of '-SNAPSHOT'
UserDisplayName: luizfzs
ThreadText: # When to get rid of '-SNAPSHOT'
  
  (Asked by: username_0 on 2018-08-14)
  
  I'm working on a Git workflow (not git-flow) for a Java project that uses Maven and Artifactory for artifact storage. On develop and feature/\* branches the version number contains '-SNAPSHOT'. It is not desirable to have release/\* or master branches with '-SNAPSHOT' so I'm trying to figure out when (and how) to get rid of it.
  
  I came up with a partial workflow, as below, but it doesn't handle removing 'SNAPSHOT':
  
  ```
                  v1.0-snap    v1.0-snap
  feature/a       * ---------> *
                  ^            |
                  |            |
                  |            v
  develop         *            * v1.0-snap
                  v1.0-snap    |
                               |
                               v        
  release/1.1        v1.0-snap * -----> *
                                      v1.1-snap
  
  ```
  
  I came up with 2 options, but both might be wrong.
  
  **Option 1**
  
  ```
                  v1.0-snap    v1.0-snap
  feature/a       * ---------> *
                  ^            |
                  |            |
                  |            v             v1.1-snap
  develop         *            * v1.0-snap  *
                  v1.0-snap    |           /
                               |          /
                               v         /
  release/1.1        v1.0-snap * -----> * v1.1-snap
                                         \
                                          \
                                           \
  master                                    * --------> *
                                            v1.1-snap   v1.1
  
  ```
  
  **Option 2**
  
  ```
                  v1.0-snap    v1.0-snap
  feature/a       * ---------> *
                  ^            |
                  |            |
                  |            v             v1.1-snap
  develop         *            * v1.0-snap  *
                  v1.0-snap    |           /
                               |          /
                               v         /
  release/1.1        v1.0-snap * -----> * ----- >* v1.1
                                     v1.1-snap    \
                                                   \
                                                    \
  master                                             *
                                                    v1.1
  
  ```
  
  Both options seems weird to me, though.
  
  Is there any best practice for this kind of flow?
  
  **Tags:** continuous-integration, git, maven
  
  > **Comments:**
  > **username_1**: How is the version mapped to the release/master branch?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-08-16. Score: 2
  
  I have a similar setup.
  
  For `feature/*` and `develop`, I use something like `18.08-SNAPSHOT` in my pom.
  When we're ready to start release hardening, I'll cut a release branch (`release/18.08`) and change the version in the pom/s to `18.08`.
  
  I'll also bump the version on develop to `18.09-SNAPSHOT`, for example.
  
  From there, bugfix and finalise the release, merge to `master` when appropriate.
  
  We're not properly CI/CD yet, but the issue I bumped in to with release builds was that I still needed unique builds in Artifactory. So, at build time (for release branches) Jenkins will change the version in the pom to something like `18.08-326` (326 being build number). It won't commit this change, but the artefact that gets built and pushed to Artifactory will be unique (`foobar-18.08-326.war`)
  
  
  ---
  
  