-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change adding methods to MINOR #93
Conversation
I've also reduced the severity of adding, removing and changing private methods and properties in traits from MAJOR to PATCH. |
docs/Ruleset.md
Outdated
@@ -29,10 +29,10 @@ V010 | MAJOR | Class public method parameter added | |||
V011 | MAJOR | Class protected method parameter added | |||
V012 | MAJOR | *New public constructor (does not match supertype)* | |||
V013 | MAJOR | *New protected constructor (does not match supertype)* | |||
V015 | MAJOR | Class public method added |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason this is a major breaking change is because someone else could be extending a class and has defined a different signature of the method that's now being added. This is why the equivalent for a final class is not major.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same reasoning for traits, but instead of extending, using the trait in a class that would already have said methods.
I don't think these changes are correct actually. |
@GrahamCampbell @tomzx you both are technically correct, adding a new method/property could break something if that method/property has already been created in the client code. However in practice for all the code libraries that I have seen this is not supported, they say that if you extend a class and add new methods/properties then it's not guaranteed to be backward compatible. For example here they say that "If you extend the class and... Add a new method... Then we guarantee BC... No". I'm working on https://www.semver-sentry.com and a lot of people have come back with feedback that they adding new methods/properties should not be a breaking change. Just brainstorming here but how about a way to set levels of individual rules through the command line? Then we could override certain rules as required. For example: $ php-semver-checker --override-level-V015=MINOR --override-level-V016-MINOR ... That would give anyone fine grain control, if needed we could also create handy flags to group these overrides like this: # This would apply strictest ruleset
$ php-semver-checker --ruleset-strict
# This would follow symfony's BC promise
$ php-semver-checker --ruleset-symfony |
@emmetog We already support customization of rules, not directly through the command line, but through a configuration file. See https://github.com/tomzx/php-semver-checker/blob/v0.11.0/docs/02-Configuration.md |
@tomzx Thanks for that, that will do the trick. |
This PR changes adding new methods to classes to be MINOR instead of MAJOR.
Discussions in favor of adding new methods not being MAJOR are here and here (Symfony say that "If you extend the class and... Add a new method... Then we guarantee BC... No").
This thread is also related.