Hi Jesse, > Prefer to harden the version # in a corporate pom. Then use > versions-m-p to detect and update bulk dependencies across all our > projects. We manage about 350 dependencies in the corporate pom
Definitely agreed. I am managing a similar number, and indeed versions-m-p is super nice for displaying which dependencies have new versions available. (Must remember to feed -U to mvn, though!) I am still looking for an easy way to answer the other question: "Have there been changes to this component since the last release" -- i.e. "Does this component need a new release" -- since we use release-ready master branches. I think the allowSnapshots property is not sufficient in my case, since the CI will always deploy a new SNAPSHOT in response to the "Bump to next development cycle" commit which does nothing else besides bump the version on master after each release. And even if somehow the versions-m-p had a magicallySolveAllMyProblems flag here, I still believe there are other use cases where RELEASE and LATEST are useful -- and that deprecating/removing them does not do anything constructive to address the problem of irreproducible builds. Regards, Curtis P.S. to Rick Huff: Thanks for taking the time to reply. :-) -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden On Mon, Apr 24, 2017 at 12:37 PM, jieryn <jie...@gmail.com> wrote: > Prefer to harden the version # in a corporate pom. Then use > versions-m-p to detect and update bulk dependencies across all our > projects. We manage about 350 dependencies in the corporate pom, and > that doesn't even include the huge number that are scope=import for > Arquillian and Selenium, etc. > > On Mon, Apr 24, 2017 at 12:58 PM, Curtis Rueden <ctrue...@wisc.edu> wrote: > >> 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 <ctrue...@wisc.edu> > 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 > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
