Adding/Removing methods that exist in the supertype

[Tom Rochette]

Note: WIP

This is a rather important aspect of semantic versioning, as the presence of a method in an ancestor class can reduce the impact of a change. For instance, we currently assume that removing a method implies a major change, while it might only mean that this method has moved to one of its ancestors.

Visibility (public, protected, private) applies to classes/interface/trait methods.

Classes

Code	Level	Rule
----	-----	- Added
VXXX	PATCH	-- Public
VXXX	PATCH	-- Protected
VXXX	PATCH	-- Private
----	-----	- Removed
VXXX	PATCH	-- Public
VXXX	PATCH	-- Protected
VXXX	PATCH	-- Private

Interfaces

Code	Level	Rule
----	-----	- Added
VXXX	PATCH	-- Public
VXXX	PATCH	-- Protected
VXXX	PATCH	-- Private
----	-----	- Removed
VXXX	PATCH	-- Public
VXXX	PATCH	-- Protected
VXXX	PATCH	-- Private

Traits

Code	Level	Rule
----	-----	- Added
VXXX	PATCH	-- Public
VXXX	PATCH	-- Protected
VXXX	PATCH	-- Private
----	-----	- Removed
VXXX	PATCH	-- Public
VXXX	PATCH	-- Protected
VXXX	PATCH	-- Private

To support this, we would be unable to simply scan the files that do not match and would have to do a complete scan of the source code in order to establish class hierarchies. Furthermore, this would mean that in the event that some supertypes are not available, we may only be able to do a partial analysis.

What we can do is first to detect files that have changed, then only load their parents as necessary, instead of scanning all the source code. This may be achievable by assuming that the code follow PSR-0 and that we can find an SPL autoloader somewhere that will take care of loading the classes we need as necessary. In case no such SPL autoloader exists, then we will do a full source code scan.