More version doc updates
parent
91fcb6cba1
commit
020805dd6f
|
@ -2,7 +2,7 @@
|
|||
tagline: Versions explained.
|
||||
-->
|
||||
|
||||
# Versions
|
||||
# Versions and constraints
|
||||
|
||||
## Composer Versions vs VCS Versions
|
||||
|
||||
|
@ -84,7 +84,7 @@ When branch names look like versions, we have to clarify for composer that we're
|
|||
|
||||
There's one more thing that will affect which files are checked out of a library's VCS and added to your project: Composer allows you to specify stability constraints to limit which tags are considered valid. In the above example, note that the library released a beta and two release candidates for version `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](../04-schema.md#minimum-stability).
|
||||
|
||||
## Writing Basic Version Constraints
|
||||
## Writing Version Constraints
|
||||
|
||||
Now that you have an idea of how Composer sees versions, let's talk about how
|
||||
to specify version constraints for your project dependencies.
|
||||
|
|
Loading…
Reference in New Issue