Page History

On this page I am trying to capture different designs, problems and solutions around Version Range processing in Mercury project. Please also read the dev@ list discussion on the subject: http://www.mail-archive.com/search?q=mercury+version+range&l=dev%40maven.apache.org^{Image Removed}

...

Design

Mercury uses a standard OSGi definition of a version range, defined in OSGi core specs 4.1,
page 39 in April-2007 PDF available on OSGi site - http://osgi.org^{Image Removed}.

The gist of it is:

• Wiki Markup\[1.2.3, 4.5.6) 1.2.3 <= x < 4.5.6 Wiki Markup
• \[1.2.3, 4.5.6\] 1.2.3 <= x <= 4.5.6
• (1.2.3, 4.5.6) 1.2.3 < x < 4.5.6
• (1.2.3, 4.5.6] 1.2.3 < x <= 4.5.6
• 1.2.3 1.2.3 <= x

Dependency Builder flow

Dependency Builder component of Mercury is responsible for

...

It uses RepositoryReader components to get all the data from repositories, in particular call readDependencies() produces a List<ArtifactBasicMetadata> which is a POM-ordered list of GAV*s. Each *V then is treated as a version range and a call is issued readVersions() for each range to produce all found range GAV's

Version Range

Main discussion point is Maven notion of release vs. snapshot. We are used to lineups such as:

1.2, 1.3-SNAPSHOT, 1.3-alpha-1, 1.3-alpha-2, 1.3-beta-1, 1.3

Wiki Markup*Debating point* - what constitutes the *range \Question to answer: what constitutes the range [1.2,1.3)* and how flexible this implementation should be?
Various options:

1. 1.2, 1.3-SNAPSHOT, 1.3-alpha-1, 1.3-alpha-2, 1.3-beta-1
2. 1.2, 1.3-alpha-1, 1.3-alpha-2, 1.3-beta-1
3. 1.2

All 3 options have use cases behind them, how general those use cases are and should all 3 options be implemented - remains open.

Solution to the above problem - Quality Range

In order to cover all the use cases regarding the upper limit of the version range, I introduced a Quality Range to Mercury. This allows us to configure Version Range to accept

1. QualityRange.ALL
2. is split into two
   1. QualityRange.ALPHA
   2. QualityRAnge.BETA
3. QualityRange.RELEASE

As a result all 3 cases could be configured into Mercury

Everybody seem to agree that plugin versioning should be identical to regular dependency versioning, so the discussion really applies to both.

...

Welcome to the debate I say that a version range should only
resolve to a snapshot if it is included as an explicit boundary. See http://jira.codehaus.org/browse/MNG-3092^{Image Removed}

You may also be interested in the other issues on my hit list for
being able to use version ranges in Maven: http://jira.codehaus.org/browse/MNG-2994^{Image Removed}http://jira.codehaus.org/browse/MRELEASE-262^{Image Removed}http://jira.codehaus.org/browse/MRELEASE-318^{Image Removed}

...

Alternative options

...

To be well rounded we should consider other approaches to dependencies

its worth having a look at how gentoo does versioning with ranges and slots... http://www.gentoo.org/^{Image Removed}http://devmanual.gentoo.org/general-concepts/dependencies/index.html^{Image Removed}http://devmanual.gentoo.org/general-concepts/slotting/index.html^{Image Removed}

...

Use Cases

Stephen Connolly wrote:

...