Is it possible to tie current git branch to project version?
Locked
12
12
 
|
Hi there,
I've seen indication when searching the internet that it isn't possible to put variables in <version> of a project (unless those variables are hardcoded <properties> or provided at the command line), but I thought I'd ask the list ... Say there was a plugin that would invoke 'git branch' to determine the current branch, and to then make that available to the project as a variable; call it ${branch}. I'd like to use this variable then in the version tag: <project> <groupId>blah</groupId> <artifactId>blah</artifactId> <version>${branch}-SNAPSHOT</version> </project> The reason I want to do this is that I'm realizing, for our internal-only code projects, that a branch is always synonymous with a version of a project, and ideally the act of being of switching branches would be all it takes to switch your maven project's version. Is this possible if I were to make a maven plugin? Thanks! Seth |
Re: Is it possible to tie current git branch to project version?
|
:-) we tag our repo with "branchname!RP-BL-mavenlabel" to help in location. Rp is for release prepare and bl is for baseline (carryover from clearcase terminology)
Just remember that in git a hash doesn't belong to a branch, it is simply attached to a linked list of hashes. A "branch" is simply a tag pointing to a hash being designated as a "head". You can just as easily use the tag created by the release plugin to checkout, and then make some bugfix branch from that location. Sent from my Blackberry. ----- Original Message ----- From: Seth Call <[hidden email]> To: [hidden email] <[hidden email]> Sent: Tue Mar 06 22:01:07 2012 Subject: Is it possible to tie current git branch to project version? Hi there, I've seen indication when searching the internet that it isn't possible to put variables in <version> of a project (unless those variables are hardcoded <properties> or provided at the command line), but I thought I'd ask the list ... Say there was a plugin that would invoke 'git branch' to determine the current branch, and to then make that available to the project as a variable; call it ${branch}. I'd like to use this variable then in the version tag: <project> <groupId>blah</groupId> <artifactId>blah</artifactId> <version>${branch}-SNAPSHOT</version> </project> The reason I want to do this is that I'm realizing, for our internal-only code projects, that a branch is always synonymous with a version of a project, and ideally the act of being of switching branches would be all it takes to switch your maven project's version. Is this possible if I were to make a maven plugin? Thanks! Seth -- View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543110.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
|
Hi Roy,
I don't understand what 'tagging our repo' means. Is this a feature of your remote repository? Sorry... I googled but I don't know what you are saying...
But aside from that, I really don't care about git hash in this question... let me explain what I'm trying to acheive... As a developer: * If I'm on branch master, I want my project version to be master-SNAPSHOT
* If I'm on branch development, I want my project version to be development-SNAPSHOT
I'd like that to happen automatically when I make the branch; I know this is rather dynamic so I assume a plugin at a minimum is required. I'm also not interested in using git local hooks if at all avoidable because they have their own drawbacks. This versioning scheme is very important; making a branch is making a new version. So, downstream projects that depend on my project:master-SNAPSHOT should *not* pickup my new branch's build artifact-not unless, of course, I go to that downstream project and change it's dependency version to say project:development-SNAPSHOT.
In summary, they are different versions, and so if you don't version your project as you make a branch, then you will now have indeterminate build resolution because 'the-last-branch-you-build-will-win' sort of problems. Also, all of this should work locally (not require a build server), so I'm limiting myself to maven-only techniques...
Any help is greatly appreciated. I hope there is some way to achieve this that I'm just not thinking of... But if anyone can say definitively that you can not put a variable in the <version> tag of an artifact, then I at least know a plugin-based solution is not an option.
Regards, Seth
On Wed, Mar 7, 2012 at 6:00 AM, Lyons, Roy [via Maven] <[hidden email]> wrote: :-) we tag our repo with "branchname!RP-BL-mavenlabel" to help in location. Rp is for release prepare and bl is for baseline (carryover from clearcase terminology) |
Re: Is it possible to tie current git branch to project version?
|
properties cannot be used where they will affect the build plan.
Therefore the following xpaths are not allowed (it may appear to work, but it will blow up in your face when you are not looking) /project/parent/* /project/groupId /project/artifactId /project/version almost anywhere else is fair game On 7 March 2012 15:18, Seth Call <[hidden email]> wrote: > Hi Roy, > > I don't understand what 'tagging our repo' means. Is this a feature of > your remote repository? Sorry... I googled but I don't know what you are > saying... > > But aside from that, I really don't care about git hash in this question... > let me explain what I'm trying to acheive... > > > > As a developer: > * If I'm on branch master, I want my project version to be master-SNAPSHOT > > * If I'm on branch development, I want my project version to be > development-SNAPSHOT > > I'd like that to happen automatically when I make the branch; I know this > is rather dynamic so I assume a plugin at a minimum is required. I'm also > not interested in using git local hooks if at all avoidable because they > have their own drawbacks. > > This versioning scheme is very important; making a branch is making a new > version. So, downstream projects that depend on my project:master-SNAPSHOT > should *not* pickup my new branch's build artifact-not unless, of course, I > go to that downstream project and change it's dependency version to say > project:development-SNAPSHOT. > > In summary, they are different versions, and so if you don't version your > project as you make a branch, then you will now have indeterminate build > resolution because 'the-last-branch-you-build-will-win' sort of problems. > Also, all of this should work locally (not require a build server), so I'm > limiting myself to maven-only techniques... > > Any help is greatly appreciated. I hope there is some way to achieve this > that I'm just not thinking of... > > But if anyone can say definitively that you can not put a variable in the > <version> tag of an artifact, then I at least know a plugin-based solution > is not an option. > > Regards, > Seth > > On Wed, Mar 7, 2012 at 6:00 AM, Lyons, Roy [via Maven] < > [hidden email]> wrote: > >> :-) we tag our repo with "branchname!RP-BL-mavenlabel" to help in >> location. Rp is for release prepare and bl is for baseline (carryover from >> clearcase terminology) >> >> Just remember that in git a hash doesn't belong to a branch, it is simply >> attached to a linked list of hashes. A "branch" is simply a tag pointing >> to a hash being designated as a "head". You can just as easily use the tag >> created by the release plugin to checkout, and then make some bugfix branch >> from that location. >> >> >> Sent from my Blackberry. >> >> ----- Original Message ----- >> From: Seth Call <[hidden email]<http://user/SendEmail.jtp?type=node&node=5543915&i=0>> >> >> To: [hidden email] <http://user/SendEmail.jtp?type=node&node=5543915&i=1><[hidden >> email] <http://user/SendEmail.jtp?type=node&node=5543915&i=2>> >> Sent: Tue Mar 06 22:01:07 2012 >> Subject: Is it possible to tie current git branch to project version? >> >> Hi there, >> >> I've seen indication when searching the internet that it isn't possible to >> put variables in <version> of a project (unless those variables are >> hardcoded <properties> or provided at the command line), but I thought I'd >> ask the list ... >> >> Say there was a plugin that would invoke 'git branch' to determine the >> current branch, and to then make that available to the project as a >> variable; call it ${branch}. I'd like to use this variable then in the >> version tag: >> >> <project> >> <groupId>blah</groupId> >> <artifactId>blah</artifactId> >> <version>${branch}-SNAPSHOT</version> >> </project> >> >> The reason I want to do this is that I'm realizing, for our internal-only >> code projects, that a branch is always synonymous with a version of a >> project, and ideally the act of being of switching branches would be all >> it >> takes to switch your maven project's version. >> >> Is this possible if I were to make a maven plugin? >> >> Thanks! >> Seth >> >> >> >> >> -- >> View this message in context: >> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543110.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5543915&i=3> >> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5543915&i=4> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5543915&i=5> >> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5543915&i=6> >> >> >> ------------------------------ >> 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-tp5543110p5543915.html >> To unsubscribe from Is it possible to tie current git branch to project >> version?, click here< >> . >> 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-tp5543110p5544417.html > Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
In reply to this post by Seth Call
Seth.
I tried doing something similar to this using the buildnumber-maven-plugin. It returns the branch and revision number (I use Subversion, not Git), but looks like you're trying something similar. The problem I encountered (at least how I interpreted it) is that the plugin doesn't run soon enough - the pom has already been interpreted before the plugin is called, so the ${branch} wasn't resolved when I needed it. I wasn't trying to change the version, but I was trying to use the property somewhere else. I think you'd have the same issue with version though. You can use the maven-release-plugin to create your branch. It prompts for a new version and updates and commits your poms automatically (at least for SVN). When/if you merge your changes back to the master branch, you'd probably need to update your versions again, but that can be accomplished with the versions plugin. HTH, Matt > -----Original Message----- > From: Seth Call [mailto:[hidden email]] > Sent: Wednesday, March 07, 2012 8:19 AM > To: [hidden email] > Subject: Re: Is it possible to tie current git branch to project > version? > > Hi Roy, > > I don't understand what 'tagging our repo' means. Is this a feature > your remote repository? Sorry... I googled but I don't know what you > are > saying... > > But aside from that, I really don't care about git hash in this > question... > let me explain what I'm trying to acheive... > > > > As a developer: > * If I'm on branch master, I want my project version to be master- > SNAPSHOT > > * If I'm on branch development, I want my project version to be > development-SNAPSHOT > > I'd like that to happen automatically when I make the branch; I know > this > is rather dynamic so I assume a plugin at a minimum is required. I'm > also > not interested in using git local hooks if at all avoidable because > they > have their own drawbacks. > > This versioning scheme is very important; making a branch is making a > new > version. So, downstream projects that depend on my project:master- > SNAPSHOT > should *not* pickup my new branch's build artifact-not unless, of > course, I > go to that downstream project and change it's dependency version to > project:development-SNAPSHOT. > > In summary, they are different versions, and so if you don't version > your > project as you make a branch, then you will now have indeterminate > build > resolution because 'the-last-branch-you-build-will-win' sort of > problems. > Also, all of this should work locally (not require a build server), so > I'm > limiting myself to maven-only techniques... > > Any help is greatly appreciated. I hope there is some way to achieve > this > that I'm just not thinking of... > > But if anyone can say definitively that you can not put a variable in > the > <version> tag of an artifact, then I at least know a plugin-based > solution > is not an option. > > Regards, > Seth > > On Wed, Mar 7, 2012 at 6:00 AM, Lyons, Roy [via Maven] < > [hidden email]> wrote: > > > :-) we tag our repo with "branchname!RP-BL-mavenlabel" to help in > > location. Rp is for release prepare and bl is for baseline > (carryover from > > clearcase terminology) > > > > Just remember that in git a hash doesn't belong to a branch, it is > simply > > attached to a linked list of hashes. A "branch" is simply a tag > pointing > > to a hash being designated as a "head". You can just as easily use > the tag > > created by the release plugin to checkout, and then make some bugfix > branch > > from that location. > > > > > > Sent from my Blackberry. > > > > ----- Original Message ----- > > From: Seth Call <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=0>> > > > > To: [hidden email] > <http://user/SendEmail.jtp?type=node&node=5543915&i=1><[hidden > > email] <http://user/SendEmail.jtp?type=node&node=5543915&i=2>> > > Sent: Tue Mar 06 22:01:07 2012 > > Subject: Is it possible to tie current git branch to project > > > > Hi there, > > > > I've seen indication when searching the internet that it isn't > possible to > > put variables in <version> of a project (unless those variables are > > hardcoded <properties> or provided at the command line), but I > thought I'd > > ask the list ... > > > > Say there was a plugin that would invoke 'git branch' to determine > the > > current branch, and to then make that available to the project as a > > variable; call it ${branch}. I'd like to use this variable then in > the > > version tag: > > > > <project> > > <groupId>blah</groupId> > > <artifactId>blah</artifactId> > > <version>${branch}-SNAPSHOT</version> > > </project> > > > > The reason I want to do this is that I'm realizing, for our > only > > code projects, that a branch is always synonymous with a version of a > > project, and ideally the act of being of switching branches would be > all > > it > > takes to switch your maven project's version. > > > > Is this possible if I were to make a maven plugin? > > > > Thanks! > > Seth > > > > > > > > > > -- > > View this message in context: > > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git- > branch-to-project-version-tp5543110p5543110.html > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > > > To unsubscribe, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=3> > > For additional commands, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=4> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=5> > > For additional commands, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=6> > > > > > > ------------------------------ > > 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-tp5543110p5543915.html > > To unsubscribe from Is it possible to tie current git branch to > project > > version?, click > > subscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB > 8LTU5NTg4MjI5Nw==> > > . > > > NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=ma > cro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.names > paces.BasicNamespace-nabble.view.web.template.NabbleNamespace- > nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%2 > 1nabble%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- > tp5543110p5544417.html > Sent from the Maven - Users mailing list archive at Nabble.com. ______________________________________________________________________ This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
|
In reply to this post by stephenconnolly
Hi Stephen,
Thank you for clarifying. That tells me what constraints I have to work with, which is a big help. Is there any intent to change these restrictions? I don't think anyone wants to change version mid-run (I've seen in other threads where you mention something about the reactor getting confused if the version were to change mid-run?), but I think there is a desire to change it 'at the start' of maven process execution in a more dynamic-yet-friendly way than just 'pass it in via command line'. The desire here, to be clear, is to give developers a correct default behavior when they type 'mvn clean install', and to never force them to type -Dproject.version = something-wrong Matt (posted after you) wanted to do something similiar point with the buildnumber plugin, too. Seth |
|
|
In reply to this post by walshmatt
Hi Matt,
Thanks for the pointer to the release plugin. My desire is to not control the process of making branches or changing versions through plugins. I want developers to be able to use git for things branch related, and use maven for compile/build related.
I think the release-plugin is trying to do too much (unless of course you want maven to do *everything* :) ) Regardless of my opinion, though, you are a big help. I'll still try to find the route I'm trying to take...
Seth
On Wed, Mar 7, 2012 at 10:03 AM, walshmatt [via Maven] <[hidden email]> wrote: Seth. |
Re: Is it possible to tie current git branch to project version?
|
|
In reply to this post by Seth Call
My view is that there are places where stuff can be inferred, such as
groupId and version of children can be inferred *if and only if* the child is always checked out with the parent (at the specified relative path)... There are plans to tackle those cases. There is, though a bit of a dual purpose to the Pom... One which may have to be split... On the one hand the deployed Pom should be fully resolved, and properties at those xpaths won't work... On the other hand, for inheritance to work we need the deployed Pom to be fully unresolved... From my point of view, those xpaths should never allow property expansion, but more smarts in inferring based on other Pom files would be good... Version numbers coming from a SCM branch name is a bad smell to me... So I would not favour without a very good case being made On Wednesday, 7 March 2012, Seth Call <[hidden email]> wrote: > Hi Stephen, > > Thank you for clarifying. That tells me what constraints I have to work > with, which is a big help. > > Is there any intent to change these restrictions? I don't think anyone > wants to change version mid-run (I've seen in other threads where you > mention something about the reactor getting confused if the version were to > change mid-run?), but I think there is a desire to change it 'at the start' > of maven process execution in a more dynamic-yet-friendly way than just > 'pass it in via command line'. > > The desire here, to be clear, is to give developers a correct default > behavior when they type 'mvn clean install', and to never force them to type > -Dproject.version = something-wrong > > Matt (posted after you) wanted to do something similiar point with the > buildnumber plugin, too. > > Seth > > > > > > > -- > View this message in context: > Sent from the Maven - Users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > |
|
|
In reply to this post by Seth Call
Just a little anecdote here on the pitfalls of branching maven projects
without some kind of control. We have a SNAPSHOT version for trunk. We use the maven-release-plugin to create our maintenance branches at release time. The plugin, by default, uses the current dev version on trunk as the branch version, and prompts for a new trunk version. Perfect. That's exactly what we want. A developer cut a dev branch from trunk several months ago, just using the normal svn copy, and didn't think about changing the version. He also created a Jenkins project for it. The dev branch sat untouched for a couple of months, then a checkin triggered a new build. Later, we were scratching our heads as to why another build dependent the trunk version of that same artifact was failing. Turns out it was using the artifact built from old code on the dev branch. After some investigation, the developer was able to pinpoint the code, which pointed to the maven artifact causing the problem. We put the branch and revision from the buildnumber-maven-plugin into the manifest, so we could see the artifact in question was built from this rarely touched dev branch. From that we were able to track the issue to the Jenkins build. A reason to control branch versions. An argument to use project-specific local repositories in Jenkins (see the "Maven concurrent builds" thread from earlier today). A good use of the manifest. And possibly even an argument in support of what you are looking for. Matt > -----Original Message----- > From: Seth Call [mailto:[hidden email]] > Sent: Wednesday, March 07, 2012 12:41 PM > To: [hidden email] > Subject: Re: Is it possible to tie current git branch to project > version? > > Hi Matt, > > Thanks for the pointer to the release plugin. My desire is to not > control > the process of making branches or changing versions through plugins. > want developers to be able to use git for things branch related, and > use > maven for compile/build related. > > I think the release-plugin is trying to do too much (unless of course > you > want maven to do *everything* :) ) Regardless of my opinion, though, > you > are a big help. I'll still try to find the route I'm trying to take... > > Seth > > On Wed, Mar 7, 2012 at 10:03 AM, walshmatt [via Maven] < > [hidden email]> wrote: > > > Seth. > > > > I tried doing something similar to this using the > > buildnumber-maven-plugin. It returns the branch and revision number > (I > > use Subversion, not Git), but looks like you're trying something > > similar. > > > > The problem I encountered (at least how I interpreted it) is that > > plugin doesn't run soon enough - the pom has already been interpreted > > before the plugin is called, so the ${branch} wasn't resolved when I > > needed it. I wasn't trying to change the version, but I was trying to > > use the property somewhere else. I think you'd have the same issue > with > > version though. > > > > You can use the maven-release-plugin to create your branch. It > prompts > > for a new version and updates and commits your poms automatically (at > > least for SVN). When/if you merge your changes back to the master > > branch, you'd probably need to update your versions again, but that > can > > be accomplished with the versions plugin. > > > > HTH, > > Matt > > > > > -----Original Message----- > > > From: Seth Call [mailto:[hidden > email]<http://user/SendEmail.jtp?type=node&node=5544568&i=0>] > > > > > Sent: Wednesday, March 07, 2012 8:19 AM > > > To: [hidden > email]<http://user/SendEmail.jtp?type=node&node=5544568&i=1> > > > Subject: Re: Is it possible to tie current git branch to project > > > version? > > > > > > Hi Roy, > > > > > > I don't understand what 'tagging our repo' means. Is this a > feature > > of > > > > > your remote repository? Sorry... I googled but I don't know what > you > > > are > > > saying... > > > > > > But aside from that, I really don't care about git hash in this > > > question... > > > let me explain what I'm trying to acheive... > > > > > > > > > > > > As a developer: > > > * If I'm on branch master, I want my project version to be master- > > > SNAPSHOT > > > > > > * If I'm on branch development, I want my project version to be > > > development-SNAPSHOT > > > > > > I'd like that to happen automatically when I make the branch; I > know > > > this > > > is rather dynamic so I assume a plugin at a minimum is required. > I'm > > > also > > > not interested in using git local hooks if at all avoidable > > > they > > > have their own drawbacks. > > > > > > This versioning scheme is very important; making a branch is making > a > > > new > > > version. So, downstream projects that depend on my project:master- > > > SNAPSHOT > > > should *not* pickup my new branch's build artifact-not unless, of > > > course, I > > > go to that downstream project and change it's dependency version to > > say > > > project:development-SNAPSHOT. > > > > > > In summary, they are different versions, and so if you don't > version > > > your > > > project as you make a branch, then you will now have indeterminate > > > build > > > resolution because 'the-last-branch-you-build-will-win' sort of > > > problems. > > > Also, all of this should work locally (not require a build > server), > > so > > > > > I'm > > > limiting myself to maven-only techniques... > > > > > > Any help is greatly appreciated. I hope there is some way to > achieve > > > this > > > that I'm just not thinking of... > > > > > > But if anyone can say definitively that you can not put a variable > in > > > the > > > <version> tag of an artifact, then I at least know a plugin-based > > > solution > > > is not an option. > > > > > > Regards, > > > Seth > > > > > > On Wed, Mar 7, 2012 at 6:00 AM, Lyons, Roy [via Maven] < > > > [hidden email] > <http://user/SendEmail.jtp?type=node&node=5544568&i=2>> > > wrote: > > > > > > > :-) we tag our repo with "branchname!RP-BL-mavenlabel" to help > > > > location. Rp is for release prepare and bl is for baseline > > > (carryover from > > > > clearcase terminology) > > > > > > > > Just remember that in git a hash doesn't belong to a branch, it > is > > > simply > > > > attached to a linked list of hashes. A "branch" is simply a tag > > > pointing > > > > to a hash being designated as a "head". You can just as easily > use > > > the tag > > > > created by the release plugin to checkout, and then make some > bugfix > > > branch > > > > from that location. > > > > > > > > > > > > Sent from my Blackberry. > > > > > > > > ----- Original Message ----- > > > > From: Seth Call <[hidden > > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=0>> > > > > > > > > To: [hidden email] > > > <http://user/SendEmail.jtp?type=node&node=5543915&i=1><[hidden > > > > email] <http://user/SendEmail.jtp?type=node&node=5543915&i=2>> > > > > Sent: Tue Mar 06 22:01:07 2012 > > > > Subject: Is it possible to tie current git branch to project > > version? > > > > > > > > > > Hi there, > > > > > > > > I've seen indication when searching the internet that it isn't > > > possible to > > > > put variables in <version> of a project (unless those variables > are > > > > hardcoded <properties> or provided at the command line), but I > > > thought I'd > > > > ask the list ... > > > > > > > > Say there was a plugin that would invoke 'git branch' to > determine > > > the > > > > current branch, and to then make that available to the project > a > > > > variable; call it ${branch}. I'd like to use this variable then > in > > > the > > > > version tag: > > > > > > > > <project> > > > > <groupId>blah</groupId> > > > > <artifactId>blah</artifactId> > > > > <version>${branch}-SNAPSHOT</version> > > > > </project> > > > > > > > > The reason I want to do this is that I'm realizing, for our > > internal- > > > only > > > > code projects, that a branch is always synonymous with a version > of > > a > > > > > > project, and ideally the act of being of switching branches > be > > > all > > > > it > > > > takes to switch your maven project's version. > > > > > > > > Is this possible if I were to make a maven plugin? > > > > > > > > Thanks! > > > > Seth > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > > > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current- > git- > > > branch-to-project-version-tp5543110p5543110.html > > > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > > > > > > > > > > > To unsubscribe, e-mail: [hidden > > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=3> > > > > For additional commands, e-mail: [hidden > > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=4> > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [hidden > > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=5> > > > > For additional commands, e-mail: [hidden > > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=6> > > > > > > > > > > > > ------------------------------ > > > > 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-tp5543110p5543915.html > > > > To unsubscribe from Is it possible to tie current git branch to > > > project > > > > version?, click > > > > > > > > > > > > subscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB > > > 8LTU5NTg4MjI5Nw==> > > > > . > > > > > > > > > > NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=ma > > > > > > cro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.names > > > paces.BasicNamespace-nabble.view.web.template.NabbleNamespace- > > > > > > nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%2 > > > > > 1nabble%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- > > > tp5543110p5544417.html > > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > > ______________________________________________________________________ > > This message, including any attachments, is confidential and > > information intended only for the person(s) named above. Any other > > distribution, copying or disclosure is strictly prohibited. If you > are not > > the intended recipient or have received this message in error, please > > notify us immediately by reply email and permanently delete the > original > > transmission from all of your systems and hard drives, including any > > attachments, without making a copy. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=5544568&i=3> > > For additional commands, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=5544568&i=4> > > > > > > > > ------------------------------ > > 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-tp5543110p5544568.html > > To unsubscribe from Is it possible to tie current git branch to > project > > version?, click > > subscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB > 8LTU5NTg4MjI5Nw==> > > . > > > NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=ma > cro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.names > paces.BasicNamespace-nabble.view.web.template.NabbleNamespace- > nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%2 > 1nabble%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- > tp5543110p5545345.html > Sent from the Maven - Users mailing list archive at Nabble.com. ______________________________________________________________________ This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
|
In reply to this post by stephenconnolly
Bad smell eh? Ok, here's my bad smell. Version numbers. Stinkier? Version *numbers* in source code. More stinky than that? Version numbers in source code for projects that are never released to the public.
I care most about the development process, and much less about the release process. If the release process is hard, that's an OK trade-off if the day-to-day development process is easy (1 release guy, 15 developers). Also, I'd argue that version numbers are usually entirely artificial, and are actually a marketing/end-user construct, and having nothing to do with source code. (ideally, they can be applied at a packaging phase, but having nothing to do with compiling/building day-to-day). Firefox went from 'normal versioning' to a major-release-every-month because they *can*. It has no tie in to anything in reality other than user expectations.
I'm a git user, and because git allows branching so easily, it allows expression of version in a very developer-friendly; through their branch. If you are using git, every time you branch, you have just said, 'I made a version'. And if your poms don't reflect that, then you have interesting new problems arise (like a build server that tracks two branchs with the same version in the pom, meaning 'last-build-of-either-branch-wins' for SNAPSHOT. That's no good, right?).
To be clear, when I talk about 'version numbers', I'm not talking about build numbers. So in my ultimate desired versioning scheme, I'd like to version every last one of our projects this way, expressed as artifact names:
Remote Repository (Artifactory, etc) would only have artifacts named: $company:$git-repository:$branch-$buildnumber $company:$git-repository:$branch-SNAPSHOT
example: acme:project-A:master-234 acme:project-A:master-SNAPSHOT acme:project-B:master-100 acme:project-B:master-SNAPSHOT Local Repository would only have artifacts named:
$company:$git-repository:$branch-local example: acme:project-A:master-local acme:project-B:master-local Now how would I use this scheme? Usage 1) I'm a project-B developer, and I *haven't checked* out project-A. I don't want to force developers to check out code that I don't need to complete a task. Project-B depends on project-A. Most of the time, I want my dependency to look like this:
<dependency> <groupId>acme</groupId> <artifactId>project-A</artifactId> <version>master-SNAPSHOT</version> </dependency>
translation: whatever the latest build on master is, I want it from the remote repository. I want to have project-B float forward with project-A, and I don't want to actively maintain that relationship.
Usage 2) If I want to use a particular build: <version>master-234</version> translation: someone broke project-A:master-235 and above. I need to pin my version to avoid this bug. Or maybe I'm working on a release variant of project-B, and I need to pin my project-A dependency. In either case, I'm still using the remote repository to resolve project-A artifacts.
Usage 3) If I want to checkout project-B, make a local-only code change, 'mvn install' it, then I can use MY version by updating my dependency to: <version>master-local</version>
translation: project-A has a bug or feature I need. I want to work on it in parallel with my changes to project-B without depending on a build server generating a project-A artifact, so I need a way to depend on project-A:master-local temporarily.
So, releasing is entirely orthogonal to this versioning scheme. I've uniquely tracked and built all of my artifacts; and that's good enough to hand off to someone else now. A release team has all they need to go then try out builds, tag a build in SCM, or whatever else they want to do to release. With all that said, I've come to realize that the versions:lock-snapshot plugin is the next best thing to having a 'local' dependency concept baked into maven (or into our workflow, as I'm trying to do) It's a very good plugin and really works to the way maven wants you to, but I'd argue that maven needs more versioning conventions/capabilities. Pinning to latest SNAPSHOT is clever, but that's not what i really care about. I want to pin to local; and so far have never wanted 'latest in time across both repositories'.
I *think* I can do what I want with this versioning scheme in maven. The main way forward is to hardcode the version in the POM to something like: <version>master-local</version>, and to override that in a build-server context with -Dproject.version=master-$BUILD_NUMBER.
The two challenges I have at the moment are: 1) dynamically changing version on branch (looks like I need git local hooks installed on every developer machine. not how i want to solve this at all). I believe the build system (maven) could and should allow this.
2) making sure I can publish both a master-SNAPSHOT artifact and a master-BUILDNUMBER artifact as the result of the same build (I'm assuming I can find a way. I don't care if it's ugly because it'll be build-server only).
By the way, super-poms are generally not something I want to use as a pattern. The smaller the project, the better. Large projects create a lot of problems (higher SCM collisions, longer build times, bigger code bases which == scarier to new progammers). While I know I can solve *some* versioning problems through super-poms, I am actively trying to avoid using those if I can help it.
Well, I hope I made a convincing enough use-case. Thanks! Seth
On Wed, Mar 7, 2012 at 1:54 PM, stephenconnolly [via Maven] <[hidden email]> wrote: My view is that there are places where stuff can be inferred, such as |
|
|
In reply to this post by walshmatt
Matt, yes, thank you.
This is *exactly* what we encountered, too. Branching *is* an expression of versioning; you have to reflect that in your pom, though, if some build system is building all these various branches and pushing these artifacts somewhere central. I referred to this problem in previous post as the 'latest-branch-to-build-wins' problem.
This is why I want to do <version>$branch-SNAPSHOT</version> or some such; if I can *declare* that, then I *know* the risk of failure is much less. I want to trust maven to resolving this variable, not the user.
And as I'm sure you found out, tracking these sorts of issues are really really hard, and cause real head scratching moments. It's much harder when the versions are different only by a day; nothing hugely different stands out to make you think... Oh my gosh I'm somehow using a very old build!
A minor epiphany: a build-number is versioning for build servers, and branches are versioning for developers! Seth On Wed, Mar 7, 2012 at 2:57 PM, walshmatt [via Maven] <[hidden email]> wrote: Just a little anecdote here on the pitfalls of branching maven projects |
Re: Is it possible to tie current git branch to project version?
|
|
In reply to this post by Seth Call
On 7 March 2012 20:59, Seth Call <[hidden email]> wrote:
> Bad smell eh? Ok, here's my bad smell. Version numbers. Stinkier? > Version *numbers* in source code. More stinky than that? Version numbers > in source code for projects that are never released to the public. > You are confusing two concepts: * version names - these are the marketing numbers associated with a product * version numbers - these are the internal development defined version numbers there may be many builds each with a different version number but tagged with the same version name... at the end of the day, only one of those version numbers will be released, so that the public sees a 1:1 but actually behind the scenes there is a N:1 > I care most about the development process, and much less about the release > process. If the release process is hard, that's an OK trade-off if the > day-to-day development process is easy (1 release guy, 15 developers). > Also, I'd argue that version numbers are usually entirely artificial, and > are actually a marketing/end-user construct, and having nothing to do with > source code. That is version names you are thinking of. > (ideally, they can be applied at a packaging phase, but having > nothing to do with compiling/building day-to-day). Firefox went from > 'normal versioning' to a major-release-every-month because they *can*. It > has no tie in to anything in reality other than user expectations. > > I'm a git user, and because git allows branching so easily, it allows > expression of version in a very developer-friendly; through their branch. > If you are using git, every time you branch, you have just said, 'I made a > version'. And if your poms don't reflect that, then you have interesting > new problems arise (like a build server that tracks two branchs with the > same version in the pom, meaning 'last-build-of-either-branch-wins' for > SNAPSHOT. That's no good, right?). Well here is the rub... say you checkout 1a2b3c4d build that... according to you that would be version 1a2b3c4d-SNAPSHOT? or would it be 1a2b3c4d modify some one file and don't check in... build it again... what is it now? it's not 1a2b3c4d because you cannot reproduce it... so it would have to be 1a2b3c4d-SNAPSHOT.... except it's not that either, because -SNAPSHOT implies it will eventually become 1a2b3c4d which it cannot as you are working on the next revision which is likely 9f8e7d6c only we cannot know that... and in git both branches and tags are completely mutable and just pointers... can't use them... I think you need to think about this a little more. > > > To be clear, when I talk about 'version numbers', I'm not talking about > build numbers. Never thought you were. > > So in my ultimate desired versioning scheme, I'd like to version every last > one of our projects this way, expressed as artifact names: > > > Remote Repository (Artifactory, etc) would only have artifacts named: > > $company:$git-repository:$branch-$buildnumber > $company:$git-repository:$branch-SNAPSHOT > I suspect that you don't fully understand how git branches work... but I am willing to be proved wrong ;-) branch names are not canonical... I can call it anything I like on my side... git push -u origin trunk:master oh look locally my branch is called trunk because I don't like calling it master... oh look fred's local name for the master branch is called fubar totally mutable > example: > acme:project-A:master-234 > acme:project-A:master-SNAPSHOT > acme:project-B:master-100 > acme:project-B:master-SNAPSHOT > > Local Repository would only have artifacts named: > $company:$git-repository:$branch-local > > example: > acme:project-A:master-local > acme:project-B:master-local > > > > Now how would I use this scheme? > > Usage 1) I'm a project-B developer, and I *haven't checked* out project-A. > I don't want to force developers to check out code that I don't need to > complete a task. Project-B depends on project-A. Most of the time, I want > my dependency to look like this: > > <dependency> > <groupId>acme</groupId> > <artifactId>project-A</artifactId> > <version>master-SNAPSHOT</version> > </dependency> > > translation: whatever the latest build on master is, I want it from the > remote repository. I want to have project-B float forward with project-A, > and I don't want to actively maintain that relationship. > > Usage 2) If I want to use a particular build: > <version>master-234</version> git tags do not increase as they are hashes, so you cannot use the hash to determine sequencing. > > translation: someone broke project-A:master-235 and above. I need to pin > my version to avoid this bug. Or maybe I'm working on a release variant of > project-B, and I need to pin my project-A dependency. In either case, I'm > still using the remote repository to resolve project-A artifacts. > > > Usage 3) If I want to checkout project-B, make a local-only code change, > 'mvn install' it, then I can use MY version by updating my dependency to: > <version>master-local</version> > > translation: project-A has a bug or feature I need. I want to work on it > in parallel with my changes to project-B without depending on a build > server generating a project-A artifact, so I need a way to depend on > project-A:master-local temporarily. > > > So, releasing is entirely orthogonal to this versioning scheme. I've > uniquely tracked and built all of my artifacts; and that's good enough to > hand off to someone else now. A release team has all they need to go then > try out builds, tag a build in SCM, or whatever else they want to do to > release. > > > With all that said, I've come to realize that the versions:lock-snapshot > plugin is the next best thing to having a 'local' dependency concept baked > into maven (or into our workflow, as I'm trying to do) It's a very good > plugin and really works to the way maven wants you to, but I'd argue that > maven needs more versioning conventions/capabilities. Pinning to latest > SNAPSHOT is clever, but that's not what i really care about. I want to pin > to local; and so far have never wanted 'latest in time across both > repositories'. > > I *think* I can do what I want with this versioning scheme in maven. The > main way forward is to hardcode the version in the POM to something like: > <version>master-local</version>, and to override that in a build-server > context with -Dproject.version=master-$BUILD_NUMBER. > > The two challenges I have at the moment are: > 1) dynamically changing version on branch (looks like I need git local > hooks installed on every developer machine. not how i want to solve this at > all). I believe the build system (maven) could and should allow this. > 2) making sure I can publish both a master-SNAPSHOT artifact and a > master-BUILDNUMBER artifact as the result of the same build (I'm assuming I > can find a way. I don't care if it's ugly because it'll be build-server > only). > > > > By the way, super-poms are generally not something I want to use as a > pattern. The smaller the project, the better. Large projects create a lot > of problems (higher SCM collisions, longer build times, bigger code bases > which == scarier to new progammers). While I know I can solve *some* > versioning problems through super-poms, I am actively trying to avoid using > those if I can help it. > > Well, I hope I made a convincing enough use-case. > Thanks! > Seth > > On Wed, Mar 7, 2012 at 1:54 PM, stephenconnolly [via Maven] < > [hidden email]> wrote: > >> My view is that there are places where stuff can be inferred, such as >> groupId and version of children can be inferred *if and only if* the child >> is always checked out with the parent (at the specified relative path)... >> There are plans to tackle those cases. >> >> There is, though a bit of a dual purpose to the Pom... One which may have >> to be split... On the one hand the deployed Pom should be fully resolved, >> and properties at those xpaths won't work... On the other hand, for >> inheritance to work we need the deployed Pom to be fully unresolved... >> >> From my point of view, those xpaths should never allow property expansion, >> but more smarts in inferring based on other Pom files would be good... >> Version numbers coming from a SCM branch name is a bad smell to me... So I >> would not favour without a very good case being made >> >> On Wednesday, 7 March 2012, Seth Call <[hidden email]<http://user/SendEmail.jtp?type=node&node=5545366&i=0>> >> wrote: >> > Hi Stephen, >> > >> > Thank you for clarifying. That tells me what constraints I have to work >> > with, which is a big help. >> > >> > Is there any intent to change these restrictions? I don't think anyone >> > wants to change version mid-run (I've seen in other threads where you >> > mention something about the reactor getting confused if the version were >> to >> > change mid-run?), but I think there is a desire to change it 'at the >> start' >> > of maven process execution in a more dynamic-yet-friendly way than just >> > 'pass it in via command line'. >> > >> > The desire here, to be clear, is to give developers a correct default >> > behavior when they type 'mvn clean install', and to never force them to >> type >> >> > -Dproject.version = something-wrong >> > >> > Matt (posted after you) wanted to do something similiar point with the >> > buildnumber plugin, too. >> > >> > Seth >> > >> > >> > >> > >> > >> > >> > -- >> > View this message in context: >> >> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545298.html >> >> > Sent from the Maven - Users mailing list archive at Nabble.com. >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5545366&i=1> >> > For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5545366&i=2> >> > >> > >> >> >> ------------------------------ >> 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-tp5543110p5545366.html >> To unsubscribe from Is it possible to tie current git branch to project >> version?, click here< >> . >> 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-tp5543110p5545543.html > Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
|
Thanks for replying Stephen. Inline to your inline!
Seth
On Wed, Mar 7, 2012 at 3:42 PM, stephenconnolly [via Maven] <[hidden email]> wrote:
I'll try to be more clear; I think I'm just not coming across. I don't care about the major/minor version numbers found in the maven versioning scheme for internal projects. If I pick a number, I have to make an effort to coerce that into meaning something, and communicate that to the team. No need to do that. Branches, however, often have meaning to people. master often means 'stable' in git. 'development' might be a noisier branch. I might make a branch per JIRA bug. Whatever; let the team decide, ala: http://nvie.com/posts/a-successful-git-branching-model/. But point is, the team would or should agree to their meaning. Making a branch called 'abeouaeou' is also just noise; I'd discourage that, but I don't think I'd have to. If I *do* have to enforce branch naming, i can do it with server-side git hooks; something that I find reasonable.
ALso, specific to your point about version numbers and version names--I'd say *both* have no meaning to me for internal projects.
(covered already, but just to be clear) I mean the major/minor versioning described in the maven versioning scheme.
'Branch', 'build number', and 'locally built' are the only 3 concepts I care about in terms of constructing a versioning scheme, and supporting the idea of 'latest' on a branch is important too.
I don't care to have a git hash in a build artifact; sorry if that was how I came across (I assume you are making hashes). When I write master-234, I mean branch + build_number_from_build_server. If I could shoe-horn the hash in the build artifact after getting all the rest of this to work for build-server built projects, then I will, because it helps you correlate to build-number-to-git-hash, but it's not a requirement.
Good point, but not an issue. If you really want to make your own-named branch locally correlated to a different-named branch in the origin repository, that is a total non-issue until something else *locally* needs to *depend* on the artifact that is created as a result of your local build. When that happens, you have to now change this project's dependency in the downstream project. I'd consider that acceptable, because, if you already have to write 'master-local' in the version field of a downstream project manually when you want to use a locally built artifact on a particular branch, then I don't mind you having to instead write 'mymaster-local' because I got creative with my local branch name. The 'changing dependency version manually' egg has already been broken in my scheme; it doesn't matter to what extent it's broken to me.
That -234 is a build-server originated number, not git hash. I don't want developer machines to ever make build-number containing artifacts for any reason. The build server is the only source of that. It will be always increasing. Or had better! :)
|
Re: Is it possible to tie current git branch to project version?
|
In reply to this post by Seth Call
2012/3/8 <[hidden email]>:
> > users Digest of: get.126118 > > Re: Is it possible to tie current git branch to project version? > 126118 by: Seth Call > > Bad smell eh? Ok, here's my bad smell. Version numbers. Stinkier? > Version *numbers* in source code. More stinky than that? Version numbers > in source code for projects that are never released to the public. Hi Seth, I think you hit the nail in the head when you questioned the semantics of artifact versions yesterday. I was researching this same problem and it came as a nice surprise to see that your suggestion of tying versions with branch names is exactly the one I was coming to. I’d like to go a little bit further in your proposal and see what you think. (I may be missing something trivial because I’m not a Java programmer, but I do support a few dozens of them by maintaining their tool chain: Subversion, JIRA, Jenkins, Sonar, Maven, Nexus, etc. Please, bear with me.) The proposal would be along these lines: * The POM artifact version tag could be specified something like this: <version>${scm.version}</version> * There should be a maven plugin that could derive the artifact version from the SCM in the following way: ** If there is a tag associated with the current revision and it complies with a specific syntax (which would default to something like /^v(\d+\.\d+\.\d+)$/, but which could be redefined by configuration) then the ${scm.version} property would be taken from the tag name as the group inside the parenthesis. (E.g., if the tag is “v1.1.2” the version would be “1.1.2”.) ** Otherwise, the ${scm.version} property would be the current branch name suffixed with “-SNAPSHOT”. (E.g., “master-SNAPSHOT”.) What benefits this would bring? Mainly, you would not need to ever edit artifact version numbers again. As it is now, when you create a release branch you have to edit the POMs in the branch (to strip the -SNAPSHOT suffix) and also edit the POMs in the trunk/master (to bump the version number) in order to differentiate versions and avoid the risk of collisions in deployment. This can be made easier by the Maven Release Plugin, but the amount of work it does to make all this editing is a bad smell to me. Feature branches are even worse. (I suspect that this is one of the reasons why feature branches are despised by some people [http://martinfowler.com/bliki/FeatureBranch.html]. But they are wrong [http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/], and I digress.) Since it’s not for a release it doesn’t make much sense to change version “numbers” in any POM. However, you’re forced to come up with an artificial new version in the POMs either in the branch or in master so that you don’t run the risk of collisions in deployment. Being forced to make-up versions are another bad smell to me. Moreover, since feature branches are frequently rebased with master, whenever master changes versions they are carried over in the next rebase and you have to be very careful to manually accept, reject or fix conflicts in the merge. Of course, when the branch is ready for the reintegration merge to master, this will happen again, only more so because reintegration merges done wrong have bigger implications. Now, with this new scheme in place you don’t have to bother anymore with version editing, because all versions are automatically derived from the SCM context, which is the authoritative place where you manage your product versions anyway. I had one minor epiphany too while thinking about this. There are good reasons to use the semantic versioning scheme [http://semver.org/] for released code. One of them is that you need to be able to order versions sequentially. In particular, you need it to be able to specify dependencies from version ranges. However, as you pointed out, branches are “development versions”. And these development versions don’t need to be ordered, just uniquely identified. For instance, when I create a feature branch it doesn’t matter what was the most recent released version number nor how many releases will be cut until the branch it is reintegrated. All that matters is that this branch is developing a unique version which is different from all other branches and releases. Usually, I want to use the latest artifact built from it, i.e., its SNAPSHOT. Now, the drawbacks... and some doubts. I understand that currently no such plugin can be implemented for maven due to a restriction on the expansion of variables in the version tag. However, since it’s possible to specify a version in the command line, it’s at least feasible to try the scheme to see how it works. I did it in a small example and it worked fine as far as I could tell. I was able to install the artifact by calling maven with the option “-Dscm.version=branch-SNAPSHOT” and it installed it correctly. Also, I’m not sure about the consequences of not using the maven standard versioning scheme [http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html] while deploying MRMs, like Nexus. In my small test I was able to deploy the branch-SNAPSHOT version successfully. Can you foresee any problem? Inferring branch and tag names from a Subversion working copy necessarily involves adherence to conversions (/trunk, /tags, /branches). But in Git or Mercurial it is trivial. It’s interesting to notice that this scheme is not completely new. In the Perl development community, Dist::Zilla [http://dzil.org/] is a tool performing similar functionality as Maven does for Java. One of the things it does quite well is to manage package version numbers automatically [http://dzil.org/tutorial/versioning.html]. As far as I know it does not have the equivalent of versioning by branch name. But it has an equivalent of the Maven Release Plugin that can infer the release version number from the tags it finds in the SCM. It works particularly well with the ::Git::NextVersion plugin [http://search.cpan.org/dist/Dist-Zilla-Plugin-Git/lib/Dist/Zilla/Plugin/Git/NextVersion.pm]. So, what do you think? Gustavo. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
|
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 |
|
|
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] <[hidden email]> wrote: Hi Gustavo, |
Re: Is it possible to tie current git branch to project version?
|
|
In reply to this post by Seth Call
2012/3/8 Seth Call <[hidden email]>
> > 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: [hidden email] For additional commands, e-mail: [hidden email] |
Re: Is it possible to tie current git branch to project version?
|
|
Em 9 de março de 2012 11:15, Gustavo Leite de Mendonça Chaves
<[hidden email]> escreveu: > > 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. This can be checked with the http://maven.apache.org/plugins/maven-enforcer-plugin/. For instance, if the artifact's version is defined like this: <version>${scm.version}</version> Then, the plugin could enforce it like this: <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-enforcer-plugin</artifactId> <version>1.0.1</version> <executions> <execution> <id>enforce-property</id> <phase>validate</phase> <goals> <goal>enforce</goal> </goals> <configuration> <rules> <requireProperty> <property>project.version</property> <message>"Please, use -Dscm.version=VERSION to specify the artifact's version."</message> </requireProperty> </rules> </configuration> </execution> </executions> </plugin> </plugins> </build> -- Gustavo --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
|
There seem to be a good deal of issues open related directly to this.
http://jira.codehaus.org/browse/MNG-2971 I'll link to this thread in the JIRA bug as a use-case for fixing it. I don't know what else to do... |
Re: Is it possible to tie current git branch to project version?
|
|
2012/3/10 Seth Call <[hidden email]>
> > There seem to be a good deal of issues open related directly to this. > > http://jira.codehaus.org/browse/MNG-2971 > > I'll link to this thread in the JIRA bug as a use-case for fixing it. Very good. That issue depends on http://jira.codehaus.org/browse/MINSTALL-50, which is about something I haven't realized yet: even though we can specify a property in the command line (e.g. -Dscm.version=1.0.0), the maven install plugin will install the original POM, with the property unexpanded. In MINSTALL-50 they are discussing a way to specify some properties that should be expanded before installation by the install plugin. Makes sense to me. I've also commented on that issue. -- Gustavo --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
«
Return to Maven - Users
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |