Hello. Le ven. 23 sept. 2022 à 15:18, Alex Herbert <alex.d.herb...@gmail.com> a écrit : > > On Fri, 23 Sept 2022 at 13:53, Gilles Sadowski <gillese...@gmail.com> wrote: > > > Hello. > > > > Le ven. 23 sept. 2022 à 12:25, Alex Herbert <alex.d.herb...@gmail.com> a > > écrit : > > > > > > The pom for RNG has many plugins that explicitly manage a version. IIUC > > > this was done to surpass the version in commons parent. However this is > > no > > > longer required. The following plugins all have a higher version in CP 54 > > > (version shown at the end of the line): > > > > > > <rng.pmd.version>3.14.0</rng.pmd.version> 3.19.0 > > > <rng.pmd.dep.version>6.37.0</rng.pmd.dep.version> 6.49.0 > > > <rng.checkstyle.version>3.1.2</rng.checkstyle.version> 3.2.0 > > > <rng.checkstyle.dep.version>8.45</rng.checkstyle.dep.version> 9.3 > > > <rng.antrun.version>1.8</rng.antrun.version> Managed in > > > org.apache:apache parent as 3.1.0 > > > <rng.surefire.version>3.0.0-M5</rng.surefire.version> 3.0.0-M7 > > > <rng.junit5.version>5.7.2</rng.junit5.version> 5.9.0 > > > > > > I propose to update to CP 54 and then drop this version management. > > > > The more is managed globally the better. However, I never understood > > the rationale for an upgrade (to "shared" files) that is known to break > > one or more components... > > > > It is impossible to tell if it will break something until the upgrade is > performed. So managing the latest version in commons parent using > dependabot will not find build errors, only update to what the plugin > developer believes is the best version. Perhaps what is really needed here > is dependabot to build selected derived projects as part of the version > update process of a parent POM.
Indeed. We'd block releases of components that fail their build, yet we release a new CP version known to break things (cf. SBOM issue which you raised), on the rationale that components that would break with the new version should stay with the old bugs (IOW not benefit from the fixes that justified the new CP). > Commons lang overrides a lot of the commons parent properties for the > validation plugins. These seem to be replicas of the same version. However > it does mean dependabot will open PRs and the build is tested before > versions are updated in the project. Since dependabot is not used (by > consensus) on RNG then this is not an option. > > I think I will just try to update to CP 54 and then serially drop each > managed dependency, resolving any issues along the way. My aim is to > simplify the RNG pom and then do the same for others with the same > structure (Statistics, Numbers, Math, Geometry). Each of the other > components have versions for these plugins that have drifted apart over > time. Ideally all the builds should work with the same versions, and > ideally the latest ones as maintained in CP. +1 Thanks for the work. but this seems a lot of "manual" work that has to be repeated each time a plugin is upgraded without checking whether it negatively impacts some component that relied on the "current" CP. My question is whether we'd not be better off requiring that any upgrade to CP either passes all the dependent (components) builds, or raises awareness for each broken build that will result from it. > Since these are build dependencies then the maintenance benefit of a common > management of versions should outweigh any upgrade issues between CP > versions. I'm not sure I understand; certainly the advantages *should* outweigh the drawbacks, but IMO, the current process (blindly accepting all "dependabot" suggestions) does not fulfill the promise. Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
