2009/2/10 Jason van Zyl <[email protected]>: > > On 10-Feb-09, at 11:33 AM, Stephen Connolly wrote: > >> 2009/2/10 Jason van Zyl <[email protected]>: >>> >>> 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] >> > > I'm honestly not concerned with what one person wants and really more > concerned what will work for thousands of users. > >> 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. >> > > I don't think. Pretty much everyone looking at many aspects in Maven > immediately say "that's not going to work for us" and then though some > process people find it's adequate. >
Yet the big plus of Maven is supposed to be version ranges, and when you are living in a land where corporate bosses have decreed 5 digits *must* be used and no rational arguments will convince them otherwise... What I'm saying is, fine, if maven works best with 4 digits, that's cool. But the current situation where a major feature just plain is broken with anything other than ###.###.###-### is not the way maven should work Mercury's current version comparison rule will handle infinite depth... there are some tweaks about whether a . or a - comes first or is ignored and that's where i'd have some concerns... 1.2.3 vs 1.2-3 vs 1.2 vs 1.2.2 vs 1.2.3.1 vs 1.2.3-1 vs 1.2.4 vs 1.2-4 in general, mercury will handle the case I have to live with, so please leave that alone ;-) >> 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. > > It's not arrogance. It's knowing in practice that when you try to get N > groups using M different schemes/processes that it quickly becomes an > untenable situation pretty quickly. It's a matter of supporting a large > group of people well. Just look at people and the problems they have just > working within a specification like J2EE or OSGi and how many problems they > have. To think that we could support interoperability between whatever > people want to arbitrarily define is frankly living in dream land. > Then you need to define a version number policy for central... as without one and a cleanup of central, you too are living in dream land >> >> >>> 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. > > Sorry, but that just doesn't work. People don't blame their messed up setup > they always, invariably blame the tools. And in this particular case I see > no advantage in not settling on a version scheme that has worked for the > last 5 years. > it has not worked with some of the crazy version numbers in central >> >> >>> 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 > > Using OSGi versioning is hardly the flavor of the month. It's also not using > OSGi it's just using a versioning scheme that has worked for a lot of people > for a long time. > > The pattern that works for us is that we pick something and settle on it and > that's what we use. We cannot put in place something that is infinitely > flexible because that fact of the matter is we end up supporting it. All the > questions from all the groups all doing totally different things falls on > us. It's very easy to say "well, you screw it up that's your problem" but > that's not what happens in practice. We will get groups who will religiously > fight about some version scheme and I just want to stay out of it. I would > opt for picking something has worked and we go with that. except that you are changing the version number rules from maven to osgi... and there is not a 1:1 mapping from maven to osgi that will preserve version ranges and it's crazy edge cases you'll get 95% of the cases, and we're left with enough of a gap to be a pain and osgi is a flavour precisely because it is different from the previous rule, and you're now changing the rules > > What is always open to you, and really what I think works best, is that you > take the source code and wedge in whatever you want. Make your own version > schemes, implement whatever you like because now you are truly responsible > for it and it is your problem. All these organizations and individuals > expect us to maintain all this stuff but when the onus falls on them they > really find out how truly painful it is. Then they really think about > whether it's really worth it or not. It forces them to help work on > something that works for everyone. > it must be great working for your own company and only getting pulled in to others as the "mr fix it" where you can force 3 digit version schemes on the company ;-) (sorry what was that, you're now forcing 4 digit schemes?) > So Stephen you are truly free to implement whatever you like. You can build > your own version of Maven using your super flexible version mechanism and if > you get adopters that's great. It's just not a long term, community wide > supportable path to take. If you don't want to work within the confines of > what we setup guess what? You don't have to use it. That is true, but I am not free to implement whatever I like. I have to bend over and take 5 digit version numbers... I personally would prefer three digits, but valid arguments have been made and that war is over, or at least not one I can fight. Add on top that we have customers taking our APIs and if they want to use Maven to build them, then they too face th 5 digit madness... and yes I made these arguments, and did I win? Guess? go on really give it a guess? Maven is a great build tool, version ranges are a seriously important feature of maven, and we cannot use them because version ranges only work for three digit version numbers... So now you have decided that OSGi is great, let's make OSGi work... well that's great, just when you're making OSGi work, don't add stuff in that breaks the rest of us mear mortals who are stuck with 5 or 6 digit version madness And don't get me started on the fools who's version number is the date they made the release... and then changed to real version numbers... so that 20030607 should be less than 1.0!!! > >> >> >>> >>>> 2009/2/10 Brian E. Fox <[email protected]>: >>>>> >>>>> 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:[email protected]] >>>>> 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > believe nothing, no matter where you read it, > or who has said it, > not even if i have said it, > unless it agrees with your own reason > and your own common sense. > > -- Buddha > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
