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:
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