Hi Peter, Peter Horlock wrote: > The problem I see with version ranges, is you start loosing control. > I guess the vital part to make the use of version ranges work (at > all) is that every developer has to follow the rule > > 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! ;-) > > 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. > > 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, > 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.
Neither Michael nor I did propose properties for the version. Simply define the version in the version depMgmnt itself and you're done. > 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? - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
