Skip to content

Adding/Removing methods that exist in the supertype #68

Open
@tomzx

Description

@tomzx

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.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions