On Thu, 30 Jan 2025 at 01:36, Gilles Sadowski <gillese...@gmail.com> wrote: > > Hi. > > Le jeu. 30 janv. 2025 à 02:05, sebb <seb...@gmail.com> a écrit : > > > [...] > > > > > > > > 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. > > In this case, yes, but it also happened, not just once, that a few components > had their build broken because the new CP made invalid assumptions (e.g. > IIRC about maven modules at the time). Sure, that didn't occur recently but > the principle is sound (IMHO): Commons' _parent_ should care for all its > components.
Agreed. I think Dependabot will generate a PR to 'bump' the CP version. This will run all the tests, so leaving updates until those have succeeded would avoid unnecessary flip-flopping. Maybe look at whether it is possible to test an RC snapshot in branches of a couple of repos before holding the VOTE to eliminate major issues. > 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
