2012/3/8 Seth Call <sethc...@gmail.com> > > Hi Gustavo, > > Wow, the tagging idea is dead on.
I'm glad that you liked it. > However, I like what you suggestion a great deal, because it allows this flow: Which seems very reasonable to me. Even more so because you wouldn't have to deal with POM editing and spurious merge conflicts anymore! Smooth and simple... > 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. Good points. They don't preclude the automatization of the release process by a simpler Maven Release plugin, though. I mean, we still can have a plugin to grok the next release version and to perform the tag automatically. Dist::Zilla::Plugin::Git::NextVersion [http://search.cpan.org/perldoc?Dist::Zilla::Plugin::Git::NextVersion] does exactly that when I run "dzil release". It groks all tags matching a regex (/^v(.+)$/ by default, order them, takes the most recent one, and create a new tag incrementing it by one. (The new tag can be specified by the user in case you want to bump the minor or the major version, but most of the time it does the right thing, much like the actual Maven Release plugin.) It would be simpler because there would be no need to edit POMs. > 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). Yes. The core principle here is DRY. Use the SCM to manage versions and let maven figure out the current version from the SCM context, avoiding the need to manually keep the SCM versions and the POM versions in sync. > 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. So do I. > 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! So far this seems to be the major roadblock to this. The risk is to let developers do builds without specifying the version and have them deployed with version "${scm.version}" instead. But, perhaps, we could at least detect it by implementing a plugin to validate the artifact version in the validate phase of the default lifecycle. It could abort the build early on if the artifact version contains an unexpanded property, for instance. > Thanks for weighing in. I was wondering if we were alone/rare in our > desired workflow... hopefully not! Let's hope. During my googling in the last days I found lots of discussions around the messiness which is the housekeeping of artifact versions in POMs. So far as I can tell, the main issues plaguing almost everybody are these: * There isn't a standard method to differentiate versions in feature branches. Some people simply don't bother and run the risk of deployment collisions. Some people manually change the artifact's groupid, putting the branch name in it. Others tend to insert the branch name in the version classifier. I couldn't find anyone (except you) thinking about using the branch name as the version. * Merges carry on the version editions performed in the POMs. These changes must be carefully screened out manually, which is error prone and potentially disastrous. By having maven infer the version from the SCM seems to simplify very much the whole process. Gustavo. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
