Le mer. 13 nov. 2019 à 17:03, sebb <seb...@gmail.com> a écrit : > > On Wed, 13 Nov 2019 at 15:12, Gilles Sadowski <gillese...@gmail.com> wrote: > > > Le mer. 13 nov. 2019 à 15:52, sebb <seb...@gmail.com> a écrit : > > > > > > On Wed, 13 Nov 2019 at 14:38, Gilles Sadowski <gillese...@gmail.com> > > wrote: > > > > > > > Hello. > > > > > > > > Le mer. 13 nov. 2019 à 14:49, sebb <seb...@gmail.com> a écrit : > > > > > > > > > > +1 for CP > > > > > > > > > > CP versions are entirely optional; > > > > > > > > Not "entirely". [We already had this discussion.] > > > > It happened that a fix for <something> was available in a newer CP but > > > > that <something else> in CP broke some components (e.g. when CP > > > > functionality is "enhanced" based on assumptions not valid for all > > > > components). > > > > Then, that *suddenly* unsupported component has to cherry-pick and > > > > duplicate (in its local POM) what exists in that newer CP which it > > cannot > > > > use anymore. > > > > > > > > > > > The newer version was still optional. > > > > > > By which I mean that it does not affect components that do not choose to > > > use it. > > > Also if a particular version is problematic, it can be ignored by all > > > components. > > > > > > In the case above, the newer CP version was faulty: it fixed some things > > > and broke others. > > > > > > Components that were affected by the breakages still had the choice to > > > continue with the previous version. > > > > Yes, at the cost of having to fix/duplicate functionality that was > > delegated > > to CP which now breaks that "promise". > > > > > They were no worse off than before > > > > It has happened, that an upgrade to a newer CP was *necessary*; for > > example, to get the new version of a plugin (and this plugin had been > > handled in CP). Now, if the CP that provides the new version broke > > something, then the plugin must now be handled at the component > > level. > > > Obviously it is not ideal that the new CP did not work for every component. > But it did not make the situation worse.
It did (because of the added work due to the necessity to diverge from CP, as examplified in the provious post). > And the next version of the CP can hopefully fix the breakage. Or not, if the component continues to diverge until someone wonders about the duplication. > > Which entails duplication, and is contrary to having a *shared* > > configuration (where improvements benefit everyone). > > > > > Of course. Glad we agree on this. > > - but of course the new version did not > > > help them either. > > > > The point is that a CP upgrade should *not* be allowed to break > > existing components that rely on the last released version. > > > > In which case we should formally vote on CP releases. Only a veto (based on the technical reason "breaks the build") would work. > > Ideally of course CP updates should always be improvements. > There are lots of different combinations of component setups, so it's very > difficult to ensure that changes will always be positive. Sure. But I still think that it when a issue arises, it should not be dismissed with the "CP is optional" argument. > However, given that there is no need to use a particular CP version, this > is not an issue. > That's why we were able to adopt a lazy vote for the CP. > > Think of a new CP version as similar to a release candidate. > If it does not work, then it is not adopted. Fine (cf. above). > Perhaps a Jenkins job could help assessing the impact of a using > > an alternative CP (?). > > > > > Feel free to set one up. > I think it would be really difficult Perhaps then: for each component who fears breakage, create a Jenkins project that track changes to CP (?). > (followups if any to a separate thread please) Well, it's all theoretical again, as for now, CP is fine; so, low priority. Hopefully, further improvement will not cut corners (e.g. assuming non-modular components). Regards, Gilles >>> [...] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
