> I would like to argue for the inclusion / restoration / continued > support of the RELEASE and LATEST tags.
Really? No one else cares enough to respond? I am very often running into use cases where the easiest solution seems to be LATEST and/or RELEASE. I have to manage a large Bill of Materials POM and I need to know things like "which components have new releases available" and "which components have SNAPSHOT builds since the last release." How do other people answer these questions without custom tooling, and without using LATEST or RELEASE tags? Regards, Curtis -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden On Thu, Apr 13, 2017 at 10:51 AM, Curtis Rueden <[email protected]> wrote: > Hi Maven developers, > > I would like to argue for the inclusion / restoration / continued support > of the RELEASE and LATEST tags. > > Reasons: > > 1) There are many valid use cases for them. For example, my script jrun > [1] uses RELEASE right now to make it easier to launch a Maven GAV. > Launching e.g. the Jython REPL is as easy as "jrun > org.python:jython-standalone" from the CLI. But this relies on RELEASE > working. I know that Maven is traditionally viewed as primarily a > build-time tool, but it is also extremely useful for synthesizing runtime > environments, and IMHO underutilized in this regard. > > 2) For LATEST, you can achieve basically the same behavior using a version > range like [0,). There is no other way (that I know of) to achieve what the > RELEASE tag does. > > 3) The argument that they harm reproducibility is totally valid. But so do > SNAPSHOTs, and so do version ranges. And those have not been deprecated. So > why are RELEASE and LATEST eschewed so heavily? > > Orthogonally: I think it would be awesome to warn about irreproducible > builds, be they from SNAPSHOTs, version ranges, or these special keywords. > People need to know when their builds are vulnerable. But there should > probably also be a property to disable this warning, for the cases when the > developer intentionally wants/needs to use them, and knows what they are > doing. If the issue is just that no ones has time to work on e.g. MNG-6206, > I could try to make some time for it—I feel strongly enough about this > issue. > > Thanks for any insight, workarounds, counterarguments, agreement. > (Especially if you agree: please speak up, so the core Maven devs know I'm > not just an outlier here!) > > Regards, > Curtis > > [1] https://github.com/ctrueden/jrun > > -- > Curtis Rueden > LOCI software architect - https://loci.wisc.edu/software > ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden >
