On Thu, 30 Jan 2025 at 00:45, Gilles Sadowski <gillese...@gmail.com> wrote: > > Hi. > > Le jeu. 30 janv. 2025 à 01:32, sebb <seb...@gmail.com> a écrit : > > > > On Thu, 30 Jan 2025 at 00:00, Gary Gregory <garydgreg...@gmail.com> wrote: > > > > > > On Wed, Jan 29, 2025 at 11:51 AM sebb <seb...@gmail.com> wrote: > > > > > > > > On Wed, 29 Jan 2025 at 16:30, Gary Gregory <garydgreg...@gmail.com> > > > > wrote: > > > > > > > > > > [NOTE: This VOTE is only open for 24 hours as version 80 requires Java > > > > > 8 to run SpotBugs] > > > > > > > > I don't see why this is urgent. > > > > Version 80 is optional; if it breaks something, just revert to 79. > > > > > > I thought I had tested the update before performing the RC, but I did > > > it incorrectly. > > > It broke all Java 8 builds on the GH CI. It is urgent to me and is a > > > clear impediment to keep things moving forward instead of > > > flip-flopping the parent dependency around. > > > > I think this shows that a new CP release should be tried in a few > > components first. > > +0.5 > > Ideal would be to have some automation that would, for every > component: > * create a branch (e.g. "master_auto_cp-80") > * run "mvn" on it > > Can GH do that? > > Then if all goes well, it's trivial to merge the change; if not, there > is at least an early warning that there is something wrong or, if > it's an intended incompatibility, something to be fixed by the > regular maintainers of the component.
That would have been a waste of resources in this case, as (nearly) all Java8 builds broke. However, for issues that only affect a few components, using a branch seems sensible, especially if the branch only runs the maven workflow. Workflows such as CodeQL etc would just be a waste of resources, and might generate more noise on the mailing lists. But this should only be done after trying a couple of components first. > Regards, > Gilles > > >> [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
