You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
Interfaces
Traits
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.
The text was updated successfully, but these errors were encountered: