On Fri, 04 Jul 2008 02:52:09 Peter Horlock wrote: > The problem I see with version ranges, is you start loosing control. Not true it means you have complete control. Unless you use [1.5] in all your versions you are asking maven to make a best effort to give you 1.5.
> I guess the vital part to make the use of version ranges work (at all) is > that every developer has to follow the rule No version ranges work fine in most cases, however I find that its best to keep it simple. You only and always change the minor version when you release an artifact unless you have branched and then you increment the patch number. The major version is a discussion with the team to say we are adding this new feature and need to make this change that will break the previous contract of the artifact. > > major.minor.patch... > > So far, we have been very loose with versions - Someone changes 5 lines in > the code, makes a new (patch) version, someone else changes another 7 > lines, makes another (patch) version, and so on - we keep on "patching" the > jar - 1.3.57 - I wonder when we will hit a hundred or a thousand! ;-) versions have nothing to do with how much or how little has changed. It usually depends on the artifact. Some are volatile and other not. The non volatile ones tend to get reused all over the place. the only time we have had broken builds was when someone made a change that broke the contract and had not discussed it. its easy enough to adjust a range if you have to e.g. [2,2.4-!) I think i might be possible to > > So I guess if EVERY developer would only use the "patch section" if it was > really just a minor patch that will not influence anything really, but > would use the minor or major section for all other changes, ranges might > work without breaking other ppls builds - but this mechanismus counts on > this very ability, which is hard to maintain, especially with new > developers joining the team. When you have strict versions everyone has to > change to a new version deliberately. I specifically set things up this was to cope with new developers, they can pick up one artifact it just works, they can build ti and release it. You can get them started and ease them into how things work. > > About the thing with version numbers as property values in the parent pom - > I am still not sure this is the best way, especially not with project that > are not really shared by others, Its a bad idea all around. it makes maintenance and nightmare and plugins and other things don't always interpolate those properties correctly, and you end up with the version being that of some obscure plugin... very annoying. > but this is the easiest way to update the dependency management section - > otherwise, when someone changes the version of a submodule, one has to > change this version, as well as the version in dep. mgmt. see previous post on sticking depMg in another common project with a pom dependency ... i dont do it this way but use a similar approach with factored dependencies > > Hmmmm, this is really hard to swallow, I can't really find THE one and only > solution of how to solve this dilemma - well, maybe I am still missing > something? -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
