Answers: <p>I suggest to follow the principles that are defined in the <a href="https://semver.org/" rel="nofollow noreferrer">Semantic Versioning 2.0.0 documentation</a>.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-22T22:36:53.953Z
Answers: 2017-11-22T22:36:53.953Z
Answers: 030
Body: <p>When dealing with publishing SOX application artifacts what is the best strategy for versioning SNAPSHOTS?</p>
  
  <p>I'm currently following the semver pattern <code>&lt;major&gt;.&lt;minor&gt;.&lt;patch&gt;</code> and wondering if it is necessary to get granular with the version strategy and append something like a git hash to the end? e.g. <code>&lt;major&gt;.&lt;minor&gt;.&lt;patch&gt;-SNAPSHOT&lt;githash&gt;</code> </p>
  
  <p>Or can I treat SNAPSHOTS as a SNAPSHOT should be and drop the hash all together?</p>
  
  <p>My argument for the latter is that SNAPSHOTS are not cut as release candidates (rc) until they actually enter the release pipeline and therefore can be clobbered, especially when following a mature CI pattern where changes are continuously merged to master following early testing validation.</p>
  
  <p>In addition to this, typically in an organization, a change request is only opened and tracked at the time you are performing a release.</p>
  
  <p>(additional convo happening <a href="https://www.reddit.com/r/devops/comments/7ekybi/sarbanesoxley_sox_versioning_strategy/" rel="nofollow noreferrer">here</a>)</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-11-22T22:38:01.303Z
Comments: What is the added value of `(additional convo happening here)`? Is this a copy or really additional information?
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2019-12-23T07:32:59.937Z
Comments: Could you indicate whether you solved the issue?
Comments: 030
Tags: <versioning>
Title: Sarbanes-Oxley (SOX) Versioning Strategy
UserDisplayName: a11hard
ThreadText: # Sarbanes-Oxley (SOX) Versioning Strategy
  
  (Asked by: username_0 on 2017-11-21)
  
  When dealing with publishing SOX application artifacts what is the best strategy for versioning SNAPSHOTS?
  
  I'm currently following the semver pattern `<major>.<minor>.<patch>` and wondering if it is necessary to get granular with the version strategy and append something like a git hash to the end? e.g. `<major>.<minor>.<patch>-SNAPSHOT<githash>`
  
  Or can I treat SNAPSHOTS as a SNAPSHOT should be and drop the hash all together?
  
  My argument for the latter is that SNAPSHOTS are not cut as release candidates (rc) until they actually enter the release pipeline and therefore can be clobbered, especially when following a mature CI pattern where changes are continuously merged to master following early testing validation.
  
  In addition to this, typically in an organization, a change request is only opened and tracked at the time you are performing a release.
  
  (additional convo happening [here](https://www.reddit.com/r/devops/comments/7ekybi/sarbanesoxley_sox_versioning_strategy/))
  
  **Tags:** versioning
  
  > **Comments:**
  > **username_1**: What is the added value of `(additional convo happening here)`? Is this a copy or really additional information?  
  > **username_1**: Could you indicate whether you solved the issue?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-11-22. Score: 1
  
  I suggest to follow the principles that are defined in the [Semantic Versioning 2.0.0 documentation](https://semver.org/).
  
  
  ---
  
  