You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Elliotte Rusty Harold (Jira)" <ji...@apache.org> on 2020/04/13 15:38:00 UTC

[jira] [Closed] (MNG-6654) Resolve version ranges to the lower inclusive bound

     [ https://issues.apache.org/jira/browse/MNG-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Elliotte Rusty Harold closed MNG-6654.
--------------------------------------

> Resolve version ranges to the lower inclusive bound
> ---------------------------------------------------
>
>                 Key: MNG-6654
>                 URL: https://issues.apache.org/jira/browse/MNG-6654
>             Project: Maven
>          Issue Type: New Feature
>          Components: Dependencies
>    Affects Versions: 3.6.0
>            Reporter: Koritako Alana
>            Priority: Major
>
> Version ranges result in non-repeatable builds because, and only because, Maven chooses the greatest version within the range.
> If we instead choose the lower inclusive bound of the range, then the build will always be the same.
> eg. [1.2.0,2.0.0.min)
> Resolving to lower inclusive bound means taking 1.2.0 here. Always. Even after 1.3.0 is released.
> Taking the lower inclusive bound means there are no holes that can later be filled in, resulting in non-repeatable builds. eg. If we took the lowest existing version in the range, then there would be a possibility of someone later adding a lower version. Taking the lower inclusive bound requires the lower inclusive bound to exist from day 1.
> Version ranges are actually for defining compatibility ranges. Conceptually, there are 2 version numbers: the version you compile against and the version range your code is compatible with. Even if you declare a version range, javac only ever compiles against 1 specific version.
> For repeatable builds, you want the version number you compile against to be the same. However, you also want to be able to declare a range of dependency versions with which your library is compatible. As Maven is now, you can't have both. By resolving version ranges to the lower inclusive bound, we can.
> This should be obvious, but to be clear: If I am writing a library liba which depends on library libb with range [1.2.0,2.0.0.min) and someone writes an app including my library liba, then the app should get version 1.2.0 of libb. The app is free to declare a direct dependency on version 1.3.0 or 1.8.5 etc of libb, any version that falls into the range [1.2.0,2.0.0.min). If the app declares a direct dependency on version 2.2.0 of libb, Maven should report a dependency resolution error like it currently does.
> But not all version ranges have a lower inclusive bound? Well, maybe they should. I honestly cant figure out a valid use for an exclusive lower bound - maybe for the lack of my imagination. Either way, I don't imagine that it would be possible to convince Maven devs to change existing behavior, so this should probably be implemented in a new version range spec scheme. ie. New version range type with new syntax that always has lower inclusive bound and always resolves to lower inclusive bound.
> Without this, I am forced to accept either non-reproducible builds or to give up strict dependency convergence assistance from Maven.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)