Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=rrOfmsvNZ58FT40ayk3gHCr3jDqpVwDEPQMfW1NLbqzS9uOXfV0/+4TS7cVOVsaA;
  h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Message-ID: <447C5B5F.1060300@earthlink.net>
Date: Tue, 30 May 2006 10:49:03 -0400
From: Joe Bohn <joe.bohn@earthlink.net>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Repository version precedence
References: <4477684B.1040900@earthlink.net>
In-Reply-To: <4477684B.1040900@earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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


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