Hervé BOUTEMY wrote:
But anyway, how
does it make sense for [1.0.0,2.0.0) (with an *exclusive* upper bound of
2.0.0) to include anything from the 2.0.0. branch?
if you don"t want to include anything from the 2.0.0 branch, you have to write
you range as [1.0.0,2.0.0-SNAPSHOT), which is consistent with the versions
ordering (no special case here)
I don't think users are
going to expect to pick up pre-production versions of 2.0.0 if they use
that as an upper exclusive bound.
you're right. They'll have to understand that 2.0.0-alpha1 is before 2.0.0,
then learn the previous way of writing their range to match their need.
If range implementation was cheated to avoid anything from the 2.0.0 branch in
[1.0.0,2.0.0) range, it lets me think we would need more tweak to support
[2.0.0-SNAPSHOT,2.0.0) range, for example.
There is a section on the link above about "define a grammar for version
specifications".
Yes, the second half of the proposal is about having a pluggable version
comparison, and a super-generic implementation as a configurable component: I
didn't work on that part, only tried to fix the current implementation.
I tried to think about it, but faced problems with this concept of pluggable
version handlers: beside having multiple implementations (or configurations
of a generic one), I don't see at what level pluggability should done:
- at the build level? but components come from a repository, and were build
with their own version scheme
- at the component level? but what if 2 versions of a component specify
different implementations?
Would it not be sensible to pick up someone else's (rational and
functional) definition? Maybe the OSGi alliance R4 spec? Many Maven jars
these days are intended by their author to be used as OSGi bundles, and the
bundle has a version with a well defined grammar.
This good reasoning has been done by other Maven developers too, independently
from this versioning proposal: for Maven 3.0, there is a full rewrite of
artifact handling in Mercury component with OSGi versioning support: see [1].
In Mercury I addressed it with having a VersionRangeFactory.create(
String version, QualityRange qRange ), the qRange defines a Quality
interval created out of [snapshot, alpha, beta and release] enumeration
for the version range upper boundary. Only quality that's inside the
specified interval is allowed to participate in version range
evaluation. Default behavior is to allow all.
I envision that in the future we'll replace enumeration with an
arbitrary, user defined sequence of code quality descriptors.
OSGi interpretation of ranges is default, with the exception of a single
version: by default "2.4" is interpreted as a "soft" range in the
dependency tree resolution - (,), but with and option it's possible to
switch to OSGi compliant [2.4,)
Hope this helps,
Oleg
