Ugh. Should have proof-read better. Step 5 should read: OPS tags **the specific git commit associated with master-26** with the tag, '1.1.2'
(so it's clear that -26 is a build number, and not a poorly written git hash example) Seth On Thu, Mar 8, 2012 at 8:59 PM, Seth Call [via Maven] < [email protected]> wrote: > Hi Gustavo, > > Wow, the tagging idea is dead on. > > With what I proposed, I didn't really address or solve how something was > released.. I just assumed when you took a build from your build server to > production, you could just tag the build in your branch for record keeping, > and away you go. > > However, I like what you suggestion a great deal, because it allows this > flow: > > 1) Developer is working on 'develop' branch. > 2) Developer merges into master. Commits. > 3) Build server builds master-26. (To bo clear, I assume the build server > dual publishes master-26 along with master-SNAPSHOT... same artifact, but > different versions, so that I have a trail of builds as well as supporting > snapshot versioning). > 4) QA verifies master-26, tells ops 'this is a good build'. > 5**) OPS tags master-26 with tag, '1.1.2' > 6**) OPS manually starts build on that specific commit using build server. > > 7**) 1.1.2 tag is incorporated into version; artifact is labeled: 1.1.2. > 8**) OPS deploys 1.1.2. > > (instead of 5-8 being a sloppier 'I stuck master-26 into production, and > tagged after the fact) > > Previous to your post, I just thought of a tag helping one track/correlate > what you released. But your tag workflow encourages one to tag up front > and *then* build, ensuring that the act of tagging occurred; and it also > encourages a tag scheme that makes sense for your 'external' versioning > scheme. Also, I like that changes to the SCM *have* to occur *before* > hand-offs to the next phase. Developer has to commit; a publisher has to > tag. Consistent. You have to actually express your intent into the SCM > before you get what you want. > > You could even enforce the tag convention by only doing some important > part of the build to make the artifact a 'release build' or 'activated' in > some way that non-tagged builds aren't. > > This particular 'scm as versioning truth' scheme, coupled with a build > server, allows a very natural hand-off between developer/qa/ops, and all > teams communicate what actually happened with one technology; the SCM. The > SCM conveys what happened throughout the entire lifecycle, and the > versioning of everything built is also tightly coupled to the SCM. (well, > one gap; I would like to shoe-horn the git hash next to the build number > for build-server artifacts, but only if it doesn't affect all my other > goals). > > But the critical question you ask... is maven OK with this versioning. I > also have seen that maven seems OK with this versioning in my tests. But I > fear my simple tests haven't found a big 'oh no'. I hope someone else > could weigh in who has a deep understanding of maven internally. > > And still, the fact we have to use the command-line to achieve this > versioning scheme is not OK. On a build server? Sure. But for developer > usage, not OK. I still strongly hope Maven could resolve this by allowing > variables in <version> that were set *very* early in the maven process. > This should be possible with a plugin! > > Thanks for weighing in. I was wondering if we were alone/rare in our > desired workflow... hopefully not! > Seth > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5549516.html > To unsubscribe from Is it possible to tie current git branch to project > version?, click > here<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB8LTU5NTg4MjI5Nw==> > . > NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5549518.html Sent from the Maven - Users mailing list archive at Nabble.com.
