On 7 March 2012 20:59, Seth Call <sethc...@gmail.com> 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] < > ml-node+s40175n5545366...@n5.nabble.com> 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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
