apache / apache/maven

[MNG-7343] Document a working migration path away from LATEST and RELEASE metaversions

Open
#8,090 5 comments 0 reactions 0 assignees View on GitHub
bug priority:major
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.