- 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.
Add a "classmap-authoritative" configuration setting that can be used to
disable searching the various prefix and fallback directories for
classes that have not been registered with the
Composer\Autoload\ClassLoader class map. This setting can be used to
optimize performance by avoiding a potentially large number of
`file_exists` calls when Composer is being used in a program with
additional autoloader facilities. Use of the setting implies
"optimize-autoloader" to ensure that the most complete class map
possible is generated.
Closes#3603
Like suggested in #1522.
These overridden packages appear only during install/update and not
when running init, show and search commands.
I don't know if they should or not.
- Implemented in self-update command
- Added to Composer\IO\BaseIO the getInputOption() and getInputArgument() getters to allow access to input
- Fixed some minor bugs