we always have pants.base.deprecated so i wouldn’t consider renaming an option to ever have a “bad time”

Well, there’s timing for end users. A deprecation is easy for us to trigger, but it still has a real impact for end users. We got feedback from a user today that the releases are really big and it’s hard to upgrade. We knew 1.25.0 was way too big already, but it’s a good reminder

if renaming an option with the exact same behavior becomes a breaking change, that would be extremely surprising to me

It’s of course not as breaking as something like

globs()

, but it is still another thing the Pants admin has to deal with. If you don’t consume dev releases, then a major release usually will include over 5-15 deprecations (guesstimate from the last few changelogs) - that’s a lot!

the reason i’m saying this isn’t to be argumentative. i’ve been working on several PRs in the background since twitter isn’t paying me to work on pants and rebasing constantly is an effort. the approach has consistently been “let’s break the entire API right now — this is a good time”. if i complained every time this broke a PR i had to spend hours to fix, people would just stop listening to me. i’m talking about the amount of changes being made each time. i don’t think “right now is a good time” is something i want to keep hearing, because it also implies later is not a good time, and i don’t have time to keep up with every single change i’d want to make right now.