geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Repository version precedence
Date Tue, 30 May 2006 15:09:47 GMT

On May 30, 2006, at 10:49 AM, Joe Bohn wrote:

> Am I the only one concerned about this?
>
> I think this is an important issue for our users.  They won't have  
> the luxury to wait for a completely new Geronimo image to fix a  
> problem with an embedded component.  They will also face these  
> issues with their own versioned application modules.  I would  
> appreciate your input.
>
> Thanks,
> Joe
>

Overall I think we need to keep consistent with maven on this.   
Having slightly different rules for geronimo compared to maven will  
create more confusion that any advantage we might gain.  There's also  
some desire to actually use the maven classes to work with  
repositories and artifacts, which would make it even more likely that  
we follow maven conventions.

I certainly think that we need very clear documentation on what the  
version numbers mean.

I think we might be able to work with maven to come up with some  
additional possibilities.  I think that our basic use case that maven  
may not support too well is producing a private build of an artifact  
that is already released from an outside project.  Currently the only  
ways to do this are by incrementing a build number (which can  
conflict with an official later release) or by incrementing the  
incremental version and including a qualifier: so
5.5.15

gets replaced by


5.5.16-MyPrivateBuild

which will in turn be replaced by any official 5.5.16 release from  
the project.

I'm not sure what problems this last might cause.

Perhaps we could lobby maven for a special qualifier keyword that is  
after all build numbers?  e.g. 5.5.15-PRIVATE-23455

A couple more comments inlne

thanks
david jencks

>
> Joe Bohn wrote:
>> 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

I'm not sure more dots are a good thing.

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

A lot of people use -DEV which is definitely before a plain build  
number.  I don't think moving most qualifiers to after build numbers  
will fly: I think a special keyword for this might.

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

I don't think these definitely need to have the same meaning.  I  
think that allowing 3 dots means we should allow any number of  
dots.... and  I'm not sure we really need the resultant complexity.


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