For 2.20, it looks like we might be close to ready...
# development
b
For 2.20, it looks like we might be close to ready? We released 2.20.0rc2 about a few days ago, we've prepped release notes and a blog post (thanks @curved-manchester-66006!) 1. I've just done another testing call out https://pantsbuild.slack.com/archives/C046T6T9U/p1712015603897529 2. Does someone want to prep and do the release itself? Also, for 2.19, it also seems like there's only been a minor doc fix since 2.19.2rc0, so maybe we could do a 2.19.2 with the small collection of fixes since 2.19.1?
s
We've switched to 2.20.0rc1, everything looks good, no regressions,
code_quality_tool
works nicely šŸ‘
šŸ‘ 1
b
Seems like all signals are good! Anyone up for prepping two stable releases? • 2.20.0 (don't forget the blog post once that's out) • 2.19.2
I took the chance to prep 2.19.2: https://github.com/pantsbuild/pants/pull/20750 we noticed an issue in 2.20, with some of the module mappings adjusted there: https://github.com/pantsbuild/pants/pull/20749 So... looks like we've gotta do another RC cycle before 2.20.0 stable.
h
Would it be OK to squeeze a deprecation of a currently unused (in the Pants repo) and pretty silly options system feature into 2.20.0?
The feature in question is "implicit_value" - what value an option takes when you provide it on the CLI with no value:
--foo
. Theoretically this is available to any option of any type. In practice it is only used for boolean options, and is always True in that case, so we can implement that directly.
This is a bad and confusing feature for multiple reasons, and I regret implementing it in 2015, which I did as part of the move off argparse, for feature parity that we didn't actually need...
So it's very unlikely that anyone is using it (it's not documented), but we must do a deprecation cycle in case somehow some plugin is using it.
It wasn't in previous rcs, but I think that's OK, since this is not destabilizing.
I will have a PR up in a bit, we can debate which version to deprecate in in that PR
Turns out the new option registration classes don't even support this feature, so it almost doesn't require a deprecation cycle. Still, just in case someone is still using old-style registration in a plugin...
b
āœ… in the PR
šŸ™ 1