You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

On this page I am trying to capture different designs, problems and solutions around Version Range processing in Mercury project.

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.

The gist of it is:

  • [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, 4.5.6] 1.2.3 < x <= 4.5.6
  • 1.2.3 1.2.3 <= x

Please note, that multi-range definition, like <version>[1,3),(3,8]</version> is gone.

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

"Maven version lineup"
1.2, 1.3-SNAPSHOT, 1.3-alpha-1, 1.3-alpha-2, 1.3-beta-1, 1.3

Debating point - what constitutes the range [1.2,1.3) and how flexible this implementation should be?
Various options:

  • 1.2, 1.3-SNAPSHOT, 1.3-alpha-1, 1.3-alpha-2, 1.3-beta-1
  • 1.2, 1.3-alpha-1, 1.3-alpha-2, 1.3-beta-1
  • 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.

Use Cases

Stephen Connolly wrote:

A slightly unrelated question:

Will there be support for version ranges with many parts (not just the three
parts that maven currently has) so that

[1.0.0.0.22,) will not pick up 1.0.0.0.9

Michael McCallum wrote:

3). Declaration [2.0, 2.1) should exclude 2.1-SNAPSHOT, but include 2.1-alpha-1, etc

Should most definitely not inlude 2.1-alpha-1 consider this scenario...

module Z released as 2.X
a dependent module Y specifies X [2,3)
you now make a breaking change and release the alpha version of Z 3.0-alpha-1
and BAM module Y is using it when it explicitly said I only want major
version 2

  • No labels