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.
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 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.
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]
