v1.1
or commit e35fa0d
--, you'reasking for a single, known set of files, and you always get the same files back.~1.1
or1.2.*
) -- is actually more specifically a version constraint. Composeruses version constraints to figure out which refs in a VCS it should bechecking out (or simply to verify that a given library is acceptable inthe case of a statically-maintained library with a version
specificationin composer.json
).1.1
) or it may reference a valid range of tags (e.g., >=1.1 <2.0
, or~4.0
). To resolve these constraints, Composer first asks the VCS to listall available tags, then creates an internal list of available versions basedon these tags. In the above example, composer's internal list includes versions1.0
, 1.0.1
, 1.0.2
, the beta release of 1.1
, the first and secondrelease candidates of 1.1
, the final release version 1.1
, etc.. (Notethat Composer automatically removes the 'v' prefix in the actual tagname toget a valid final version number.)vendor
directory.dev-*
prefix (or sometimes suffix; see below). If you're checking out a branch, it's assumed that you want to work on the branch and Composer actually clones the repo into the correct place in your vendor
directory. For tags, it copies the right files without actually cloning the repo. (You can modify this behavior with --prefer-source and --prefer-dist, see install options.)my-feature
branch, you would specify dev-my-feature
as the version constraint in your require
clause. This would result in Composer cloning the my-library
repository into my vendor
directory and checking out the my-feature
branch.v1
and v2
. To get Composer to check out one of these branches, you must specify a version constraint that looks like this: v1.x-dev
. The .x
is an arbitrary string that Composer requires to tell it that we're talking about the v1
branch and not a v1
tag (alternatively, you can name the branch v1.x
instead of v1
). In the case of a branch with a version-like name (v1
, in this case), you append -dev
as a suffix, rather than using dev-
as a prefix.1.1
before the final official release. To receive these versions when running composer install
or composer update
, we have to explicitly tell Composer that we are ok with release candidates and beta releases (and alpha releases, if we want those). This can be done using either a project-wide minimum-stability
value in composer.json
or using 'stability flags' in version constraints. Read more on the schema page.1.0.2
>
, >=
, <
, <=
, !=
.,
) will be treated as a logical AND. A double pipe (||
)will be treated as a logical OR. AND has higher precedence than OR.>=1.0
>=1.0 <2.0
>=1.0 <1.1 || >=1.2
1.0 - 2.0
is equivalent to >=1.0.0 <2.1
as the2.0
becomes 2.0.*
. On the other hand 1.0.0 - 2.1.0
is equivalent to>=1.0.0 <=2.1.0
.1.0 - 2.0
*
wildcard. 1.0.*
is the equivalent of>=1.0 <1.1
. Certificates templates for pages 1 0.1.0.*
~
operator is best explained by example: ~1.2
is equivalent to>=1.2 <2.0.0
, while ~1.2.3
is equivalent to >=1.2.3 <1.3.0
. As you can seeit is mostly useful for projects respecting semanticversioning. A common usage would be to mark the minimumminor version you depend on, like ~1.2
(which allows anything up to, but notincluding, 2.0). Since in theory there should be no backwards compatibilitybreaks until 2.0, that works well. Another way of looking at it is that using~
specifies a minimum version, but allows the last digit specified to go up.~1.2
2.0-beta.1
is strictly before 2.0
, a version constraintlike ~1.2
would not install it. As said above ~1.2
only means the .2
can change but the 1.
part is fixed.~
operator has an exception on its behavior for the majorrelease number. This means for example that ~1
is the same as ~1.0
asit will not allow the major number to increase trying to keep backwardscompatibility.^
operator behaves very similarly, but it sticks closer to semanticversioning, and will always allow non-breaking updates. For example ^1.2.3
is equivalent to >=1.2.3 <2.0.0
as none of the releases until 2.0 shouldbreak backwards compatibility. For pre-1.0 versions it also acts with safetyin mind and treats ^0.3
as >=0.3.0 <0.4.0
.^1.2.3
-dev
or -stable
, depending on theoperator(s) used. This happens transparently.-stable
.Constraint | Internally |
---|---|
1.2.3 | =1.2.3.0-stable |
>1.2 | >1.2.0.0-stable |
>=1.2 | >=1.2.0.0-dev |
>=1.2-stable | >=1.2.0.0-stable |
<1.3 | <1.3.0.0-dev |
<=1.3 | <=1.3.0.0-stable |
1 - 2 | >=1.0.0.0-dev <3.0.0.0-dev |
~1.3 | >=1.3.0.0-dev <2.0.0.0-dev |
1.4.* | >=1.4.0.0-dev <1.5.0.0-dev |
@<stability>
(e.g. @dev
) to let composer know that a given packagecan be installed in a different stability than your default minimum-stabilitysetting. All available stability flags are listed on the minimum-stabilitysection of the schema page.composer.json
file. You can adjust theversion constraint and the tool will highlight all releases that match.