Thanks for replying Stephen. Inline to your inline! Seth
On Wed, Mar 7, 2012 at 3:42 PM, stephenconnolly [via Maven] < ml-node+s40175n5545703...@n5.nabble.com> wrote: > On 7 March 2012 20:59, Seth Call <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5545703&i=0>> > 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'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. > > > 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. > (covered already, but just to be clear) I mean the major/minor versioning described in the maven versioning scheme. --- http://docs.codehaus.org/display/MAVEN/Versioning '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. > > > (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. > 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. > > > > > > 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 > > 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. > 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. > 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! :) > > > > > 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] <http://user/SendEmail.jtp?type=node&node=5545703&i=1>> > 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]<http://user/SendEmail.jtp?type=node&node=5545703&i=2> > For additional commands, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=5545703&i=3> > > > > ------------------------------ > 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-tp5543110p5545703.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-tp5543110p5545887.html Sent from the Maven - Users mailing list archive at Nabble.com.
