Open Ocramius opened 6 years ago
YAML seems like a great idea :trollface:
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?
@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.
Agreed, I know about this library and it would be nice, but it requires PHP 7.1 :trollface: , 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 :see_no_evil: . So we are for now using this "low-end" solution...
@OndraM so how are you making this package work?
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.
Gotcha. Simply keep an eye on when you can drop <7.1 ;-)
Will defer this: building a separate entry-point is still the preferred way at the time of this writing.
We currently ship a massive single block of BC compliance rules hardcoded via dependency injection. It would be interesting to configure rules as following:
Where
SomeInvokableClass implements BCRulesConfiguration
or such.Overall, I'd avoid weird
.xml
or such when not needed.