[MNG-7343] Document a working migration path away from LATEST and RELEASE metaversions
- Dominant language
- Java
- Stars
- 5.3k
- Forks
- 3.1k
- Avg merge
- 20h 42m
- Merged PRs (30d)
- 297
Description
**[Curtis Rueden](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=ctrueden)** opened **[MNG-7343](https://issues.apache.org/jira/browse/MNG-7343?redirect=false)** and commented
I use LATEST and RELEASE a lot for various purposes, such as CLI tooling that automatically synthesizes POMs to perform various tasks. I personally feel deprecating these metaversions was a mistake—I find them incredibly useful, with the understanding that I would never use them for production reproducible builds. But I do understand the rationale: we don't want to encourage anyone to use these in a way that harms the stability of dependency resolution, reproducibility-wise. So I'm OK with it, as long as there is a migration path forward for these sorts of use cases.
But what is that path? I cannot find a way to replicate either of the metaversion behaviors using version ranges. There are problems with version ranges (MNG-3092, MNG-6049) preventing them from being used as a replacement for LATEST or RELEASE. Furthermore, in my tests, specifying a version range like `[0,)` causes Maven to download POMs at a bunch of (maybe all?) versions of an artifact, whereas `LATEST` and `RELEASE` do not trigger en masse downloading.l
Is there a non-deprecated syntax that has equivalent behavior? As things stand, I am concerned that support for these metaversions is going to disappear in a future version of Maven without a feasible migration path forward.
---
1 votes, 2 watchers
Contributor guide
Assessment
This issue has not been assessed yet.