I see this one regularly and don't frankly understand the need other than pure theory. Actual version comparison supports every numbering scheme I ever saw in reality. The only choice that has been made that is a pure choice (neither good nor bad, just a choice had to be made) is that unknown qualifiers are considered after known ones [1].
Do you have practical examples that either are not supported, or the actual ordering is the contrary than you expected? I'm really interested, because in the first case, I need to add support for something new, but only the second needs a pluggable version comparison algorithm Then if we really need this one, we'll have the problem of *where* we should configure the value: project-level is a nightmare if ever really possible, CLI doesn't make sense IMHO, then we have user-level or install level But even at user or install level, I doubt this will be usable Regards, Hervé [1] http://maven.apache.org/ref/3.0.4- SNAPSHOT/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html Le dimanche 31 juillet 2011, Stephen Connolly a écrit : > oh i forgot to mention. i also think that version comparison rules should > be plugable. > > - Stephen > > --- > Sent from my Android phone, so random spelling mistakes, random nonsense > words and other nonsense are a direct result of using swype to type on the > screen > On 31 Jul 2011 08:27, "Stephen Connolly" <stephen.alan.conno...@gmail.com> > > wrote: > > i see two concerns that need separation. > > > > 1. the code that fetches dependencies from wherever they live. > > > > 2. the code that computed the dependencies graph. > > > > #1 should be something that is plugable, and in essence could be part of > > the > > > repositories definitions... in saying that, i think we need a way to > > separate the current project build infrastructure from the fixed > > information > > > inherent in tagging the codebase for a release. the projects repositories > > and issue tracker, are things which can evolve over time, and having them > > fixed in an immutable pom is bad for users. if we can find some way of > > fixing that concern then that would be a good thing. > > > > #2 is a different beast. i think forcing the osgi scheme on users is bad > > for > > > users. i could be selfish and say that i no longer work for a telecom > > company that insists on 5-6 segment version numbers (depends on how you > > choose to release as to whether one of those segments applies) but > > forcing > > 4 > > > segments on those users is wrong. i don't mind making life a little > > harder for people venturing away from maven's opinionated view, but > > forcing > > people > > > to conform to get full functionality is bad for users. where this all > > fits in is defining which versions fall within a defined range, and how > > to > > choose > > > a version from within that range. > > > > iirc osgi does allow hinting in regard for which end of the range to > > favour, > > > but because of its classloading isolation, there is less of a problem for > > osgi. osgi being designed to solve the 2 dependencies needing conflicting > > versions of the same dependency problem. > > > > i am more willing to view #2 as being something that we should be looking > > into not being plugable, but instead allow hints to the impl to say which > > end of the range to favour... closest hint wins (sort of) > > > > however we do need a clear separation between exposing that as a maven > > api and whatever code we have solving that graph for us. > > > > - Stephen > > > > --- > > Sent from my Android phone, so random spelling mistakes, random nonsense > > words and other nonsense are a direct result of using swype to type on > > the screen > > On 31 Jul 2011 07:41, "Mark Struberg" <strub...@yahoo.de> wrote: --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
