Breaking change for the plugin interface so bumping the version of
composer-plugin-api to 2.0.0
First step for a refactoring of the package metadata loading mechanism
A negative list of non-feature-branches names
is already supported - this patch adds a list of
branches names which *will* be considered as
feature branches.
Allows changing the currently hardcoded set of
expected feature branch names, from:
* master|trunk|default|develop
To any set of names or patterns that you desire.
Current versions of Git output the commit hash as detached HEAD instead
of FETCH_HEAD. The VersionGuesser should be able to handle commit hashes
as well as FETCH_HEAD to detect the correct branch of a commit.
Working towards #3545.
This adds VersionParser::$stabilities, which is an array of the
supported stability levels. This adds a little bit of duplication,
however we were already hardcoding the various stabilities in regular
expressions and functions like parseStability().
Working towards #3545.
formatVersion() does not belong in VersionParser since it depends upon a
Package object, and is creating a more complete pretty formatted
version, not parsing anything.
The new getFullPrettyVersion() method can be seen as an extension to
getPrettyVersion(), and is located in BasePackage as a result.
Callers to VersionParser::formatVersion() were not updated in this
commit to demonstrate that no functionality was changed in this
refactor. They will be updated in a follow up commit.
This is a change to the >=2.3.0 comparison. Without this change, such a
comparison will exclude pre-release versions.
The rationale is that this makes the comparison more consistent with
<2.3.0 (which excludes all pre-releases) and ~2.3.0 (which includes
pre-releases).
- 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.
According to http://php.net/manual/en/function.preg-match.php and some other sources named groups should contain a 'P' character after the '?'
Without this, I receive the following error when running an update:
[ErrorException]
preg_match(): Compilation failed: unrecognized character after (?< at offset 4
Exception trace:
() at phar:///var/www/git/smmqa/app/admin/composer.phar/src/Composer/Package/Version/VersionParser.php:181
This also modifies the behavior slightly (from a recommendation by seldaek) to always
propose the minor version of the recommendation (e.g. ~1.2 instead of ~1.2.1).
The lower bound of ~1.2 and 1.2.* style version requirements now uses >= 1.2.0.0-dev instead of
> 1.1.9999999.9999999. This is more straightforward to read, and behaves equivalently.
Jordi Boggiano
Matthew Brown
CZechBoY
Nils Adermann
闫兴茂
Alessandro Lai
Jérôme Vasseur
Claus Due
Nicole Cordes
James Buncle
Rob Bast
bohwaz
Steve Buzonas
Niels Keurentjes
Sash
Samuel ROZE
Kunal Mehta
Sam Minnee
nevvermind
Hannes Van De Vreken
Chris Brand
Damian Mooyman
François Pluchino
Ryan Weaver
Pascal Borreli
Pavel Savinov