geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Repository version precedence
Date Fri, 26 May 2006 20:42:51 GMT
I'm trying to get my head around the way that we make a version 
selection when multiple versions of a package are available.   This will 
be important as users need to include different versions of packages 
beyond what geronimo bundles or if they need to override a package with 
a local version.

I was working with the tomcat jars and so I was looking for ways to drop 
in a modified version of the jars and have them picked up without 
removing the 5.5.15 versions.   Here are the items that I tried and 
which was chosen when compared to 5.5.15

1) 5.5.15.1
-  Apparently any version with more than 2 dots is considered invalid 
and so the entire version is considered to be a qualifier (with a null 
for the major, minor incrementalVersion, and build - basically treated 
as 0.0.0-"5.5.15.1"). Any valid version is considered newer.
-  5.5.15 is chosen over 5.5.15.1
-  5.5.10 is chosen over 5.5.15.1

2) 5.5.15-1
-  The "-" is used to specify a qualifier or buildnumber.  Since the 
value after the dash was numeric, it was considered to be a buildnumber. 
  It appears that a build number is always considered newer than a 
package without a buildnumber.
-  5.5.15-1 is chosen over 5.5.15

3) 5.5.15-01
-  The code (Version.java) treats the leading "0" as a special case. 
This makes the last part a qualifier rather than a build number.  Any 
qualified version is considered to be lower than a non-qualified version 
(such as with -SNAPSHOT).  Anybody know why this special check for "0" 
is in there?
-  5.5.15 is chosen over 5.5.15-01

4) 5.5.15-alpha
-  If the portion following the "-" starts with an alphabetic character 
then this last portion is considered a qualifier.  Once again, the 
qualified release is considered older than the same version non-qualified.
-  5.5.15 is chosen over 5.5.15-alpha


First, we need to document this behavior very clearly for users that 
need to replace packages we ship (or their own packages included in the 
repo).

Second, I would like to propose some changes:
-  IMO a qualified release should generally be considered *newer* than a 
non-qualified release.  I think SNAPSHOT would be the only exception. 
Right now we treat that exception as the rule for all qualifiers. I 
think we should add specific code for "SNAPSHOT" and have all other 
qualified releases take precedence over a non-qualified release.  I can 
imagine users wanting to add myjar-1.1-patch1.jar to replace 
myjar-1.1.jar.
-  I think we should treat a third "." to be the logical equivalent of a 
"-" in the version.  Most users would expect 5.5.15.1 to be major 
version 5, minor version 5, incremental version 15, 
build/rev/patch/whatever 1 and consider this to be newer than 5.5.15. 
See #1 above for how we really treat 3 dots.  Providing 5.5.15-1 gives 
substantially different results than providing 5.5.15.1 which is not 
intuitive.

Joe


-- 
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Mime
View raw message