1. Be open to cutting stable releases more frequently. I imagine this would basically take the form of rephrasing https://www.pantsbuild.org/release_strategy.html from “[The release manager should cut a new stable] if it has been approximately one month since the previous stable branch [and see if there are any issues which should justify delaying]” to something like “Any committer who wants a stable release can cut a release candidate branch at any time. They should make sure that there are no glaring bugs before cutting (but should not delay a release waiting for new features).” The major down side here is it somewhat wreaks havoc on deprecations. Currently the semi-predictable cadence of releases means deprecations have a semi-predictable duration. Otherwise, having more releases seems pretty harmless to the general community (in fact, it should make each individual update easier, so should make things easier for people), and the extra costs are absorbed by whoever wants the extra releases.

i would like deprecation cycles to remain as two stable releases, what i've been doing is rounding up from the current dev release to two stable releases after that.