Giters

tomzx / php-semver-checker

Compares two source sets and determines the appropriate semantic versioning to apply.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Should parameter name change rules be removed?

tomzx opened this issue · comments

commented

In all of the cases, a parameter name change generates a PATCH increment. Furthermore, changing a parameter name will also most likely imply method implementation changes as well which are also PATCH increment. Thus, those rules are most likely only generating noise, that is information that is not very interesting. Finally, it is generally of no interest to the callers/client code if a parameter name has changed.

Affected rules
V060 - Class public method parameter name changed
V061 - Class protected method parameter name changed
V062 - Class private method parameter name changed
V063 - Interface method parameter name changed
V064 - Trait public method parameter name changed
V065 - Trait protected method parameter name changed
V066 - Trait private method parameter name changed

Thus, I suggest the removal of the mentioned rules from the ruleset.

commented

Is it possible to keep them but not enable them in the default build ?

commented

That could be an alternative, but then that would open the door to having other rules not available in the default build... I wouldn't mind as long as they're adding value to the overall tool.

What value do you see in keeping those rules available?

commented

Maybe sometimes some people analysing the change of an api will want to know about the parameter name change just because there isn't any other change and it might improve their overall comprehension of the api they are using.

Or maybe you should get rid of it and not look back. I just wouldnl't reuse those rule numbers to avoid confusion.

commented

Rule number reuse is certainly out of the question. It is basically the main reason they're there to begin with: unique identifiers.

Thanks for your feedback!