Why is adding a protected/public method considered MAJOR?

[Anahkiasen]

Semver 2.0 says:

MINOR version when you add functionality in a backwards-compatible manner, and

But currently PSC reports protected/public methods (or classes) added as a BC when I can't see why it would be. When one is removed yeah sure, but not added, no?

[GrahamCampbell]

Why is adding a protected/public method considered MAJOR?

Is that not adding them to an interface that's major?

[Anahkiasen]

Hm no I just tested with latest version and I'm getting like a billion MAJOR warnings from methods added to all kinds of classes.

[Anahkiasen]

Although that's the latest phar, let me test with master

[Anahkiasen]

No yeah same thing with latest master.

[tomzx]

You can refer to the Ruleset for the current set of rules and their triggered level. Furthermore, it is possible to configure the triggered level via the config flag (see #3).

Adding a public/protected (V015 and V016) method is considered major as it could be in conflict with existing method of classes extending the modified class. Think about the following

<?php

class ChangedClass {
    public function newMethod();
}

class ClassExtendingChangedClass extends ChangedClass {
    public function newMethod();
}

Here newMethod was added by the user before the library decided it would add a method with the same name.

Thus, adding public/protected could technically break the client's code. At some point I thought about making it MINOR with a warning flag (or have some flag passed telling whether your code is an application or a library), but determined the most common case would be librairies, where doing so would most likely cause issue to their users.

[Anahkiasen]

While I agree with the intent that is one hell of a constraint to follow in an actual project, how would you ever add a feature without adding any methods nor classes? If I had to tag a MAJOR everytime I added a protected method I'd be at version 512.0.0 or something :d

[tomzx]

@Anahkiasen Agreed. But that is what stability entails.

I'm open to any suggestion that would make it more useful in other situations. Maybe have some sort of strict and loose configuration that is shipped with PSC? Strict would be the current implementation, and loose would consider things that shouldn't generally occur as minor annoyance (such as forcing the user to rename his methods).

[mikeSimonson]

@tomzx I think, that I am going to disagree a bit with your justification on why adding a method is MAJOR.

It's MAJOR only if it might be needed to extend your class which is ( in my impression ) not the general case for a library. But the only way to know that the class is not going to be extended is if it's marked as final.

Maybe the rule should be updated with that difference in mind ?

[tomzx]

@mikeSimonson, I did plan/account for the final modifier (see Ruleset rules V017, V018, V021 & V022 for instance), but no code has been written to take it into account. I've rarely seen any library use it though (not a reason to do it, but only pointing that out).

I've added #49, which should take care of adding final related rules. I'll complete the description of the issue when I have some time.

[tomzx]

@mikeSimonson Please go take a look at #49 and let me know what you think about the suggested rules.

Thanks!

[tomzx]

I'm closing this, please refer to #49 and #51 for final related rules.

Feel free to keep discussing the issue here if you do not agree with the suggested fix.