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.
