2009/2/10 Jason van Zyl <jvan...@sonatype.com>: > On 10-Feb-09, at 8:37 AM, Stephen Connolly wrote: > >> Which is why I think that the rules need to be defined at the >> repository, and per groupId >> > > That's just a nightmare. What's wrong with just settling on something that > works for everyone. I really and truly can't honestly see how the OSGi > versioning scheme can't work for folks. > > Every organization and their uncle will come with some reason why their > BigCo must have 5 digits and 2 qualifiers. It's just fodder for disaster.
Because 5 digits can actually be a good thing.... Yes, I would love to have something other than [Major].[Minor].[Service pack].[patch].[build] But given that we've had several builds of patches to a specific service pack, it's a nightmare to get that information into 4 digits.... and yes, I know windows uses only 4 digits... but come on. If Maven is going to force 4 digits down our necks that's a bad thing. Personally, mercury's infinite number of versions is nice.... I think it should work for everyone, but I am not so arrogant as to assume that it will. > The interoperability issues like when someone takes an existing project in > open source and renames it to their scheme, then you have two repositories > that have the similar artifacts with different versioning schemes and I just > don't think it's worth it. Then people start having to make bridges between > these different systems. > If it's defined at the repository level per groupId, you just leave that up to the repository manager... if you have a private repo with differing rules, fine, if you use those rules in somebody else's groupId, your build will be f*cked, and it's your problem. > Why don't we just use a scheme that has been around for years and seems to > be accommodating and working for organizations like Eclipse? They have spend > a lot of time thinking about and do we really want to get into a debate > about why 4 digits are better then 3, or why we should sort qualifiers this > way or that? > > My opinion is that we gravitate toward the OSGi version scheme and be done > with it. We could make the scheme pluggable but I would basically say if you > want to deviate you can support the additional tooling required to deal with > it. As long as the version comparison works for those people who must use more than 4 digits, I'm fine if Maven moves to 4 digits in general. But *stop* assuming that, just because 4 digits is your latest flavour of the month, 4 digits is best > >> 2009/2/10 Brian E. Fox <bri...@reply.infinity.nu>: >>> >>> Once multiple resolution strategies start appearing, life will be >>> infinitely more complicated. If you use a different strategy and I >>> consume your artifacts, I need to be able to interpret your strategy and >>> use it when calculating your part of the tree. (and someone else's etc). >>> That means the strategies need to be implemented and available in the >>> repository for mercury to use. >>> >>> -----Original Message----- >>> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] >>> Sent: Tuesday, February 10, 2009 3:32 AM >>> To: Maven Developers List >>> Subject: Version comparison rules >>> >>> OK, here's a hairy old chestnut... >>> >>> Maven has a set of version comparison rules... they don't work for >>> everyone... well life sucks >>> >>> Mercury has a new set of version comparison rules... they're a lot >>> better, but probably don't work for everyone... life still sucks... >>> >>> I've been thinking, the reality is that version comparison rules are >>> very much an organisation thing... so they really should be defined by >>> the organisation... >>> >>> In versions-maven-plugin, I've added a third version comparator... it >>> won't work for everyone... life still sucks... >>> >>> What I'm thinking is that if we had some metadata associated with the >>> groupId, it could specify what the version comparison rule is for that >>> groupId (and all it's child groupIds)... >>> >>> OK, so I can do something similar in versions-maven-plugin to let >>> people define their rules for their groupIds, but this is something >>> that should really go into the repository... a >>> version-comparison-metadata.xml file... >>> >>> we can start easy, by just defining the root rule as the current maven >>> rules... >>> >>> The maven-deploy-plugin and nexus/artifactory could then use that rule >>> to update the latest and release tags in the metadata.xml files... ok, >>> so Maven 2.0.x could ignore the rules, or a small change could add >>> support... >>> >>> What do people think... >>> >>> We could even define the v-c-m.xml file to handle rule change-over, so >>> that we don't break existing builds... >>> >>> e.g. >>> >>> <rules> >>> <rule regex="..." priority="9999">maven</rule> >>> <rule regex="..." priority="1">mercury</rule> >>> </rules> >>> >>> so that versions matching mercury's regex will have a high priority >>> and use mercury's rule within, while versions matching maven's regex >>> will always be older than those matching mercury's regex, but will be >>> compared with each other using maven's rules >>> >>> -Stephen >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > We all have problems. How we deal with them is a measure of our worth. > > -- Unknown > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
