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 -- View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5549516.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
