I definitely see both sides of this one. TL;DR: there might be a middle ground that could lean on things we’re already doing…
The sheer number of tiny little tasks that go into a given major core release is probably not obvious to the casual observer- we’ve tried different ways over the years to address them with some combination of:
- Eliminate (yay!)
- Make declarative/single source of truth
- Make atomic
- Provide CI accountability
Those last two are important for keeping things from falling through the cracks. A great example of this is the relatively recent work that went into new sanity tests for deprecations and standardized deferred deprecations.
Before the recent-ish changes, they were horribly messy- deprecated features would often linger for several major releases beyond their scheduled demise because they were non-standard or someone forgot to go grep for them. Hunks of dead code got left lying around, or we’d miss starting a deprecation clock on something at the earliest opportunity. Deprecations are intrinsically non-atomic, since resolving one occurs multiple releases later, but we were able to compensate for that by adding CI accountability, which has worked out fabulously.
The previous way we were doing CI target removals was non-atomic for the convenience of collection maintainers, and IIRC there were several times where we forgot to close the loop on the removal. We switched to atomic removal to avoid that, which, agreed, sucks for collection maintainers when things suddenly start going red with no other changes. Our (perhaps flawed) reasoning at the time was that most collection maintainers were unlikely to be watching for the warnings anyway, so even with a warning period, most collections would still end up in the same state.
Going back to non-atomic target removals and using something like out-of-band GH issues/labels for the followup kinda works against the “declarative/single-source-of-truth” element.
Maybe there’s a lightweight (waves hands) way to add deprecation metadata to a test target that would both issue runtime warnings when used, and be consumed by a simple sanity test that would automatically start failing after, e.g., beta1. We lose atomicity, but at least it’s back in our faces when it’s time to actually zap the entries. This could probably be done consistently with the way we handle deprecations when a devel version bumps, and might even be able to use the same underlying mechanisms.