Opinions on how to mark something as deprecated, but without plans to actually remove? An issue is our reference docs. @flat-zoo-31952 I think has pointed out it's helpful to still show up in the docs, only make clear it's deprecated

Seems pretty reasonable

set

removal_version="3.0"

to show that it will only be removed in a major version bump.

Cool, now we have a new tool to keep backwards compatibility 🙂 Another tool I still want to add is aliases for goal names (

generate-lockfiles

vs

lock

)

I would like aliases for

goal names + default options

haha

that exists 🙂

[cli].alias

https://www.pantsbuild.org/docs/reference-cli

https://www.pantsbuild.org/docs/reference-cli?

we could do a better job probably documenting it elsewhere. I'm not sure where it belongs

oh that's just like git alias p. much nice

thanks to @curved-television-6568

Minor feat 😂

First PR trying this out: https://github.com/pantsbuild/pants/pull/16582 I'm still very tempted to instead set a long deprecation that we remove in say 4 pants versions...I think that's the purist in me not liking seeing the old code & deprecated stuff in

help

. But maybe that's the pain of us making a mistake when we first added this. For options that are cheap to support both, thoughts on indefinite support vs long deprecation?

Old code there is not much to do about, it's the price you pay. Deprecated help sounds incidental. We could do different things like hiding from help after some period. You can still show it with some flag, but it hides after some period. IOW, we won't break you but we also won't give you easy access to the old help, there will only be pointers in the new option that it replaced the old as a paranthetical. That's one way anyhow.

Solid point that we need not let this clutter

help

. So, then we only have code clutter. This is easy enough to support that I agree we should deal with it