we always have pants.base.deprecated so i wouldn’t...
# development
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
👍 1
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
, 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!
I’m one of the main culprits for deprecations, and I’m not blaming anyone or saying we need to stop them. Often the deprecations are good. Only, we need to consider how many we’re making at the same time and remember it does impact the end user.
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.
and also, separate from the higher level argument you’re making, i don’t think it’s correct that changing a single option with the same behavior is a breaking change. i’d like to specifically focus on the change we’re referring to.