Make BC compliance rules configurable

[Ocramius]

We currently ship a massive single block of BC compliance rules hardcoded via dependency injection. It would be interesting to configure rules as following:

./bin/roave-backward-compatibility-check --rules=SomeInvokableClass

Where SomeInvokableClass implements BCRulesConfiguration or such.

Overall, I'd avoid weird .xml or such when not needed.

[asgrim]

YAML seems like a great idea

[OndraM]

Hi, just to add possible usecase: we are using constant which identifies library version, and on new release (ie. constant value change) we are getting this:
- [BC] CHANGED: Value of constant Lmc\Matej\Matej::VERSION changed from '1.5.0' to '1.6.0'
what is obviously intentional and not a BC break.

So I guess this could be covered by this issue?

[Ocramius]

@OndraM modifying constants is in most cases a BC break, so yes, it would need customisation if you wanted to exclude it. My tip is to move away from that kind of versioning, and just use ocramius/package-versions instead, which solves the issue upfront.

[OndraM]

Agreed, I know about this library and it would be nice, but it requires PHP 7.1 , and we need to maintain this specific library compatible with PHP versions having security support, which is unfortunately still PHP 5.6 and 7.0 🙈 . So we are for now using this "low-end" solution...

[Ocramius]

@OndraM so how are you making this package work?

BackwardCompatibilityCheck/composer.json

Line 5 in 9e95a60

"php": "^7.2",

[OndraM]

Well Travis build which includes this BC check (together with codestyle and phpstan checks) is run solely on PHP 7.2 environment, while phpunit is run also on older PHP versions.

Also because of the PHP 7.2 dependency, this package is only installed in this build.

[Ocramius]

Gotcha. Simply keep an eye on when you can drop <7.1 ;-)

[Ocramius]

Will defer this: building a separate entry-point is still the preferred way at the time of this writing.