Greetings, * Chapman Flack (c...@anastigmatix.net) wrote: > On 03/01/22 14:14, Stephen Frost wrote: > >> There can't really be many teams out there thinking "we'll just ignore > >> these scripts forever, and nothing bad will happen." They all know they'll > >> have to do stuff sometimes. But it matters how we allow them to schedule > >> it. > > > > We only make these changes between major versions. That's as much as we > > should be required to provide. > > It's an OSS project, so I guess we're not required to provide anything. > > But in the course of this multi-release exclusive to non-exclusive > transition, we already demonstrated, in 7117685, that we can avoid > inflicting immediate breakage when there's nothing in our objective > that inherently requires it, and avoiding it is relatively easy. > > I can't bring myself to think that was a bad precedent.
It's actively bad because we are ridiculously inconsistent when it comes to these things and we're terrible about ever removing anything once it's gotten into the tree as 'deprecated'. Witness that it's 8 years since 7117685 and we still have these old and clearly broken APIs around. We absolutely need to move *away* from this approach, exactly how 2dedf4d9, much more recently than 7117685, for all of its other flaws, did. > So if I'm outvoted here and the reason is "look, a lighter burden is > involved this time than that time", then ok. I would rather bow to that > argument on the specific facts of one case than abandon the precedent > from 7117685 generally. It's far from precedent- if anything, it's quite the opposite from how most changes around here are made, and much more recent commits in the same area clearly tossed out entirely the idea of trying to maintain some kind of backwards compatibility with existing scripts. Thanks, Stephen
signature.asc
Description: PGP signature
