RE: Version comparison rules
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=maven/rule rule regex=... priority=1mercury/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
Re: Version comparison rules
Which is why I think that the rules need to be defined at the repository, and per groupId 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=maven/rule rule regex=... priority=1mercury/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
Re: Version comparison rules
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. 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. 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. 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=maven/rule rule regex=... priority=1mercury/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
Re: Version comparison rules
Stephen Connolly schrieb: 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)... It would be very cool to have some general purpose grouplevel metadata! Various things come to mind. Public keys, extensible general purpose grouplevel indexing, group relocation, group depraction, access control etc. Lots of usecases. So when modeling, lots of requirements to collect. Could be as complex as the pom itself, could be as simple as group file id=well-known-identifier mime-type=text/xml url=version-comparison-metadata.xml/ file id=well-known-identifier mime-type=application/x-x509-ca-cert url=ca.crt/ file id=well-known-identifier mime-type=image/jpeg url=logo.jpg/ ... /group With URLs relative to the groupid location or even absolute pointing to some resource outside the repository, but publicly accessible, or not. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Version comparison rules
Christian Schulte schrieb: Stephen Connolly schrieb: 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)... It would be very cool to have some general purpose grouplevel metadata! Various things come to mind. Public keys, extensible general purpose grouplevel indexing, group relocation, group depraction, access control etc. Lots of usecases. So when modeling, lots of requirements to collect. Could be as complex as the pom itself, could be as simple as group file id=well-known-identifier mime-type=text/xml url=version-comparison-metadata.xml/ file id=well-known-identifier mime-type=application/x-x509-ca-cert url=ca.crt/ file id=well-known-identifier mime-type=image/jpeg url=logo.jpg/ ... /group With URLs relative to the groupid location or even absolute pointing to some resource outside the repository, but publicly accessible, or not. There currently is no possibility for something like 'artifactGroup.getArtifacts()', is there ? -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Version comparison rules
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=maven/rule rule regex=... priority=1mercury/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
Re: Version comparison rules
Brian E. Fox wrote: Once multiple resolution strategies start appearing, life will be infinitely more complicated. yes :( I think Mercury has a pretty decent potential to cover majority of the reasons to change version comparisons. For example - there is a notion of version quality and repository only accepting a range of qualities. Version ranges also allow to configure quality behavior on the edges - like: is 2.0-SNAPSHOT in the range [1.0,2.0) is configurable. 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. Also consider that version comparison affects behavior of dependency resolver, and what has been tested for one set of rules, could easily break under another rule-set. Which means - that we only hope that everything works correctly, but not guarantee it does. Overall - organizations start playing with these rules when they lack other tools, and try to adopt their process to the limitations of tools they have. I think we should leave version comparison alone, and instead - concentrate on the tools. For example - Nexus goes a long way here, allowing a lot of flexibility in the usage, and thus removing the necessity to change those rules. Using it immediately allows organization to tweak their process without knocking build tooling off it's feet. -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=maven/rule rule regex=... priority=1mercury/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
Re: Version comparison rules
On 10-Feb-09, at 11:33 AM, Stephen Connolly wrote: 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] 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. 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. 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. 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. 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. So Stephen
Re: Version comparison rules
2009/2/10 Jason van Zyl jvan...@sonatype.com: On 10-Feb-09, at 11:33 AM, Stephen Connolly wrote: 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] 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
Re: Version comparison rules
On 10-Feb-09, at 1:06 PM, Stephen Connolly wrote: 2009/2/10 Jason van Zyl jvan...@sonatype.com: On 10-Feb-09, at 11:33 AM, Stephen Connolly wrote: 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] 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... Otherwise what? You go down the path of explaining it's not supported and that you can implement it yourself. Explain the costs associated with that and see if your boss likes it. Nothing is free. Us supporting it here would be marginal at best because we can't know what everyone is going to do is just not supportable from a project perspective. I am certain we can find something that works for 90% of the user base. For the rest of the 10% of the cases that are so far out there those groups are responsible for supporting them. Version ranges have never worked well so we're basically going to get to decide what happens and I don't think anyone is going to argue about taking in input. But I would really be loathe at this point to do something different then OSGi versioning. This doesn't imply terminally tying to OSGi, it's just their version scheme. 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 ;-) What Mercury can handle and what will happen in Maven are two separate things. Mercury was designed to do everything and they were designed to be completely decoupled. 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 Then you can see how having many would be that many more times untenable. Getting N projects in the world in line will take at least a year, and it will not happen until we have Nexus managing everything. Right now central just gets contributed to and it's a convenience to the Maven community to populate their own. We know first hand what's sitting in there. It's grown organically and I think that's fine as it shows what people want and what people do. 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
Re: Version comparison rules
Sent from my [rhymes with myPod] ;-) On 10 Feb 2009, at 19:05, Jason van Zyl jvan...@sonatype.com wrote: On 10-Feb-09, at 1:06 PM, Stephen Connolly wrote: 2009/2/10 Jason van Zyl jvan...@sonatype.com: On 10-Feb-09, at 11:33 AM, Stephen Connolly wrote: 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] 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... Otherwise what? You go down the path of explaining it's not supported and that you can implement it yourself. Explain the costs associated with that and see if your boss likes it. Nothing is free. Us supporting it here would be marginal at best because we can't know what everyone is going to do is just not supportable from a project perspective. I am certain we can find something that works for 90% of the user base. For the rest of the 10% of the cases that are so far out there those groups are responsible for supporting them. Version ranges have never worked well so we're basically going to get to decide what happens and I don't think anyone is going to argue about taking in input. But I would really be loathe at this point to do something different then OSGi versioning. This doesn't imply terminally tying to OSGi, it's just their version scheme. 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 ;-) What Mercury can handle and what will happen in Maven are two separate things. Mercury was designed to do everything and they were designed to be completely decoupled. 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 Then you can see how having many would be that many more times untenable. Getting N projects in the world in line will take at least a year, and it will not happen until we have Nexus managing everything. Right now central just gets contributed to and it's a convenience to the Maven community to populate their own. We know first hand what's sitting in there. It's grown organically and I think that's fine as it shows what people want and what people do. 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
