Do not count "skipped" changes as BC breaking

[bshaffer]

We are getting a lot of "skipped" errors. Some are because of classes that have been renamed and aliased using class_alias, and some which are from older versions of dependencies. But either way, these errors are not between versions, but rather, they exist in both versions. So I do not think they should count as BC breaks.

What is the reasoning for marking "skipped" changes as breaking BC? Can we set Change::$isBcBreak to false [1] for these types of changes?

[lcobucci]

What is the reasoning for marking "skipped" changes as breaking BC? Can we set Change::$isBcBreak to false [1] for these types of changes?

My understanding is that "skipped" was created as a wider category but is only being used for parsing errors. Given we can't tell for sure if a parsing error would or not yield a BC-break, they're always considered as a breaking change.

Perhaps #737 might help you 👍

[Ocramius]

Indeed, they were designed to capture "crashes" that should be caught and lead to a failure.

Not sure about it nowadays: would be able to be more precise with a BC break and some new ENUM logic in a new major 🤔

[bshaffer]

@lcobucci yes, that feature would help us immensely!

@Ocramius we were able to fix the crashes in other ways (marking classes as internal, removing other dependencies). I would be worried about the potential for one of these to not be so easy to fix someday, though.