<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>

CC BY-SA 4.0
2018-08-16T15:48:34.043Z
2018-08-16T16:01:37.087Z
2018-08-16T16:01:37.087Z
Denham Coote
<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>

CC BY-SA 4.0
2018-08-19T21:54:45.133Z
How is the version mapped to the release/master branch?
gmolaire
<continuous-integration><git><maven>
When to get rid of '-SNAPSHOT'
luizfzs
# 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`)


---

