- changed "SPI" into something more familiar, like "implementation"
- throw exceptions on invalid implementation types or invalid class names
- use null instead of false when querying
- refactored the tests accordingly
Plugins can now present their capabilities to the PluginManager, through which it can act accordingly, thus making Plugin API more flexible, BC-friendly and decoupled.
This reverts commit 21f5933e01.
Commit 21f5933e breaks fresh installations of cakephp applications, or
any project where a dependency uses a different composer plugin
installer than the upstream project.
Closesauraphp/Aura.Intl#20
- Move the version api getter to the PluginManager And make it such that it can be mocked, but not pollute the public interface. That means "protected" visibility.
- The plugin api version constant should still be used throughout the code.
- Use different fixtures class names
- Use regex possessive quantifiers for performance
- Use full words for readability
Instead of developing plugins against a single, fixed Plugin API version - `"composer-plugin-api": "1.0.0"`, this change will allow plugin developers to use versions like `"composer-plugin-api": "~1.1"` or `"composer-plugin-api": ">=2.1 <3.0"`, aka actual Composer-compatible constraints.
Only the "1.0", "1.0.0" and "1.0.0" Plugin API versions will be regarded as BC versions, and internally converted to "^1.0"; every other declared version string will be kept as it is.
Because of this new constraint flexibility, plugin version mismatches will be skipped, which means those plugin will NOT be registered to the system. Previously, a mismatch triggered a warning, but plugins were still registered.
Gabriel Caruso
Jordi Boggiano
Andreas Möller
Felix Becker
Martin Hasoň
Fabien Potencier
Michele Locati
Andrii Vasyliev
nevvermind
Jose Diaz-Gonzalez
Rob Bast
Jérémy Derussé