ok, in the past i have had discussions with Jason over version range syntax. Jason previously expoused the view that osgi format version numbers is the -only- way to have version numbers, and anything else he would not support.
at the time i was working for a company where we had 5 segment version numbers. major.minor.servicepack.patch.build and the reality is that we needed all 5. if version ranges can work with any number of segments, that solves my itch (besides working for a new company without such issues) qualifier sorting is something where i see being opinionated as a value, but number of segments is not. the other case is where you need to change the scheme. rpm has a second field called, iirc epoch. it is integer and increments when you change the version number scheme... if we had provides scope then we just say change G or A coordinates... otherwise we need some epoch like support to version numbering. - 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 11:19, "Hervé BOUTEMY" <herve.bout...@free.fr> wrote: > Le dimanche 31 juillet 2011, Mark Derricutt a écrit : >> The use case that we originally came with in our discussions revolved >> around version ranges, > ok, that's not a version comparison but version (range) resolution question: > version ordering is here to define how artifacts are ordered, then the range > has to choose which one is to be used effectively > Multiple strategies can make sens here, but we should be careful on how to > provide them. > > This lets the question of pluggable version comparison need: is there a real > world example of unwanted version order? > > Regards, > > Hervé > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org >
