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 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...
They are a superset. Or close enough to a superset that it's not
going to cause that many problems. There are a few things like "1.0"
having totally different behavior but the version scheme and the
behavior we can separate for the time being.
and there is not a 1:1 mapping from maven to osgi that will preserve
version ranges and it's crazy edge cases
Our stuff I would say doesn't work well enough to preserve. And
aside from some "." to "_" conversions it's not really that bad.
Maven 2.x will always support what's there and that's not going to
change.
you'll get 95% of the cases, and we're left with enough of a gap to
be a pain
I doubt it. It won't be any worse then what we have now.
and osgi is a flavour precisely because it is different from the
previous rule, and you're now changing the rules
The set notation is almost the same, the rules are slightly
different yes but I think our model is sufficiently broken that we
take one that works. We have no real specification to speak of so
it's really not that much of an advantage sticking to what we have
because no one can ready anything about it.
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.
Tell them it's going to cost them 40k/year in maintenance costs
doing something completely differently.
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?
Then keep adding to that number. It's going to cost you real money.
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...
Then you expose your own hooks to Mercury and do your own 5 digit
thing. Or you figure out how to do three digits and use the
qualifier to do whatever else you want.
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
I don't think we would change the way it is now, if the version
doesn't parse you string comparisons. But I think you could probably
do something with qualifiers.
our versions are always numbers and 5 sets of them separated by only .
the most important thing is that build 6 < build 16
osgi will map the first 4 of them fine... but if qualifiers are
compared as strings we really need to know that we will only have less
than 99 builds or we run into issues. last release we had 162 builds,
previous took only 25
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 <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
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: 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
----------------------------------------------------------
A language that doesn’t affect the way you think about programming i
s not worth knowing.
-— Alan Perlis
---------------------------------------------------------------------
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
