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] < [email protected]> 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<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-tp5543110p5545543.html Sent from the Maven - Users mailing list archive at Nabble.com.
