Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Update: deprecate id-blacklist rule #13465
What is the purpose of this pull request? (put an "X" next to an item)
[x] Documentation update
What changes did you make? (Give an overview)
I noticed that in the haste to rename
Regarding documentation, note that some tooling of tooling (well, tooling I use, anyway) expects the rule to have documentation matching the name of the rule.
Is there anything you'd like reviewers to focus on?
Just to make sure this was done in the desired/appropriate manner.
The decision not to deprecate the rule was a conscious one. We thought that creating a URL redirect on the website would be enough. I'm not against marking the rule as deprecated if the direction we took is breaking things, but do you mind sharing a concrete example of what's breaking?
Deprecation sounds good because it looks confusable for tools if the same rule exists as two different names and both are not deprecated.
I have a small concern about the deprecated rule imports the living rule. We have made the code of deprecated rules frozen until this. Therefore, I feel odd a bit if we will continue to update the new deprecated rule. But it's not a strong feeling because this is rename.
Thanks all: I'll definitely jump on that soon. While I do so, may I suggest that we document this rule about deprecated rules being frozen in developer docs somewhere. I think it's a great policy to have and it seems like it's worth making official.
I'd be happy to make a issue+PR if so (we can discuss where it should live in the issue maybe?)
I think the policy is already documented here:
Maybe it isn't explicit enough that the behavior of the rule will never change?
Hm, actually if it happens that a deprecated rule uses some shared helpers like