geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <jsisson.apa...@internode.on.net>
Subject Re: Plugin version numbers
Date Mon, 27 Feb 2006 01:44:16 GMT
Discussed this on IRC with David Jencks and Brett Porter and it was 
noted that we require the plugin-build-number to overcome problems with 
Maven 1's handling of SNAPSHOT plugin versions.

Brett reminded me that M1 does not interpret the contents of a version 
string (except for searching for the string 'SNAPSHOT' I assume).

Once the plugins move to M2 we should use SNAPSHOTs for the plugins and 
won't need the build number.

FYI: Brett pointed out that if the format Dain proposed was used in M2, 
M2 would interpret the last number of the version following the '-' 
character as a build number not a qualifier, so it would be sorted 
numerically, unlike a qualifier that is sorted lexicographically.

Brett also confirmed a build number in M2 has a special meaning, e.g. 
"usually means the code is untouched, but it is rebuilt (different 
configuration, or something like that, kind of unusual)".

So in summary there isn't an issue with Dain's proposal when used on M1.

John

John Sisson wrote:
> I found the following Maven pages describing versions (I don't know if 
> these are out of date):
> 
>    
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution 
> 
> 
>    http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
> 
> In the 2nd URL above it says that the version section of a Maven version 
> should be numeric.  It describes a version being in the format:
> 
>    <major>.<minor>.<revision>([ -<qualifier> ] | [ -<build>
]).
> 
> You are proposing that we have a '-' character in the revision section 
> (using Maven's terminology) which doesn't agree with the numeric 
> requirement.  The doc also says that a revision is optional and will 
> default to ".0" if not set.  So I'm not sure if Maven will see a 
> non-numeric revision and then default the revision to ".0" and then use 
> the revision containing the '-' as a qualifier.  If it is used as a 
> qualifier, it looks like the qualifier is lexicographically compared, 
> therefore geronimo_deployment_plugin_version=1.2.0-10 will be less than 
> geronimo_deployment_plugin_version=1.2.0-2 .
> 
> I haven't looked at the code to confirm any of this.  Maybe one of the 
> Maven guys could confirm what happens to your proposed 
> <geronimo-micro>-<plugin-build-number> containing the '-' character.
> 
> Regards,
> 
> John
> 
> Dain Sundstrom wrote:
>> I think we have a problem with the current version numbering of 
>> plugins.  We are using the following scheme to generate the version 
>> numbers:
>>
>> <geronimo-major>.<geronimo-minor>.<plugin-build-number>
>>
>> The first two match the geronimo version and the last is a number that 
>> is incremented with each change to the plugin (this forces maven to 
>> download the new version).  I think this scheme will break as soon as 
>> we do a geronimo release that has a micro (3 dotted) revision.  We 
>> haven't seen this problem yet in Geronimo but we almost saw it when we 
>> were working on geronimo 1.0.1.  I propose we change to the following 
>> scheme:
>>
>> <geronimo-major>.<geronimo-minor>.<geronimo-micro>-<plugin-build-number>
>>
>> Using this scheme HEAD version plugin version numbers would be:
>>
>> geronimo_packaging_plugin_version=1.2.0-3
>> geronimo_assembly_plugin_version=1.2.0-8
>> geronimo_deployment_plugin_version=1.2.0-1
>> geronimo_dependency_plugin_version=1.2.0-1
>>
>> branches/1.1 would become:
>>
>> geronimo_packaging_plugin_version=1.1.0-2
>> geronimo_assembly_plugin_version=1.1.0-8
>> geronimo_deployment_plugin_version=1.1.0-1
>> geronimo_dependency_plugin_version=1.1.0-1
>>
>> We could optionally leave off the extra .0 before the dash but I think 
>> we should leave it in for clarity.
>>
>> I'd like to implement this quickly since the build is broken due to me 
>> changing the trunk version to 1.2 and not incrementing the plugins.  
>> So please let me know quickly if you have an issue with the changes[1].
>>
>> -dain
>>
>> [1] We can always back the changes out but we could have published 
>> plugins that have bad version numbers, which is something I'd like to 
>> avoid.
>>
>>
>>
>>
> 
> 

Mime
View raw message