dependabot-composer 0.111.16 → 0.111.17

data/helpers/vendor/composer/composer/doc/articles/troubleshooting.md

@@ -0,0 +1,309 @@
+<!--
+    tagline: Solving problems
+-->
+# Troubleshooting
+
+This is a list of common pitfalls on using Composer, and how to avoid them.
+
+## General
+
+1. Before asking anyone, run [`composer diagnose`](../03-cli.md#diagnose) to check
+   for common problems. If it all checks out, proceed to the next steps.
+
+2. When facing any kind of problems using Composer, be sure to **work with the
+   latest version**. See [self-update](../03-cli.md#self-update) for details.
+
+3. Make sure you have no problems with your setup by running the installer's
+   checks via `curl -sS https://getcomposer.org/installer | php -- --check`.
+
+4. Ensure you're **installing vendors straight from your `composer.json`** via
+   `rm -rf vendor && composer update -v` when troubleshooting, excluding any
+   possible interferences with existing vendor installations or `composer.lock`
+   entries.
+
+5. Try clearing Composer's cache by running `composer clear-cache`.
+
+## Package not found
+
+1. Double-check you **don't have typos** in your `composer.json` or repository
+   branches and tag names.
+
+2. Be sure to **set the right
+   [minimum-stability](../04-schema.md#minimum-stability)**. To get started or be
+   sure this is no issue, set `minimum-stability` to "dev".
+
+3. Packages **not coming from [Packagist](https://packagist.org/)** should
+   always be **defined in the root package** (the package depending on all
+   vendors).
+
+4. Use the **same vendor and package name** throughout all branches and tags of
+   your repository, especially when maintaining a third party fork and using
+   `replace`.
+
+5. If you are updating to a recently published version of a package, be aware that
+   Packagist has a delay of up to 1 minute before new packages are visible to Composer.
+
+6. If you are updating a single package, it may depend on newer versions itself.
+   In this case add the `--with-dependencies` argument **or** add all dependencies which
+   need an update to the command.
+
+## Package not found on travis-ci.org
+
+1. Check the ["Package not found"](#package-not-found) item above.
+
+2. If the package tested is a dependency of one of its dependencies (cyclic
+   dependency), the problem might be that Composer is not able to detect the version
+   of the package properly. If it is a git clone it is generally alright and Composer
+   will detect the version of the current branch, but travis does shallow clones so
+   that process can fail when testing pull requests and feature branches in general.
+   The best solution is to define the version you are on via an environment variable
+   called COMPOSER_ROOT_VERSION. You set it to `dev-master` for example to define
+   the root package's version as `dev-master`.
+   Use: `before_script: COMPOSER_ROOT_VERSION=dev-master composer install` to export
+   the variable for the call to composer.
+
+## Package not found in a Jenkins-build
+
+1. Check the ["Package not found"](#package-not-found) item above.
+2. Reason for failing is similar to the problem which can occur on travis-ci.org: The
+   git-clone / checkout within Jenkins leaves the branch in a "detached HEAD"-state. As
+   a result, Composer is not able to identify the version of the current checked out branch
+   and may not be able to resolve a cyclic dependency. To solve this problem, you can use
+   the "Additional Behaviours" -> "Check out to specific local branch" in your Git-settings
+   for your Jenkins-job, where your "local branch" shall be the same branch as you are
+   checking out. Using this, the checkout will not be in detached state any more and cyclic
+   dependency is recognized correctly.
+
+## I have a dependency which contains a "repositories" definition in its composer.json, but it seems to be ignored.
+
+The [`repositories`](../04-schema.md#repositories) configuration property is defined as [root-only](../04-schema.md#root-package). It is not inherited. You can read more about the reasons behind this in the "[why can't
+composer load repositories recursively?](../faqs/why-can't-composer-load-repositories-recursively.md)" article.
+The simplest work-around to this limitation, is moving or duplicating the `repositories` definition into your root
+composer.json.
+
+## I have locked a dependency to a specific commit but get unexpected results.
+
+While Composer supports locking dependencies to a specific commit using the `#commit-ref` syntax, there are certain
+caveats that one should take into account. The most important one is [documented](../04-schema.md#package-links), but
+frequently overlooked:
+
+> **Note:** While this is convenient at times, it should not be how you use
+> packages in the long term because it comes with a technical limitation. The
+> composer.json metadata will still be read from the branch name you specify
+> before the hash. Because of that in some cases it will not be a practical
+> workaround, and you should always try to switch to tagged releases as soon
+> as you can.
+
+There is no simple work-around to this limitation. It is therefore strongly recommended that you do not use it.
+
+## Need to override a package version
+
+Let's say your project depends on package A, which in turn depends on a specific
+version of package B (say 0.1). But you need a different version of said package B (say 0.11).
+
+You can fix this by aliasing version 0.11 to 0.1:
+
+composer.json:
+
+```json
+{
+    "require": {
+        "A": "0.2",
+        "B": "0.11 as 0.1"
+    }
+}
+```
+
+See [aliases](aliases.md) for more information.
+
+## Memory limit errors
+
+Composer may sometimes fail on some commands with this message:
+
+`PHP Fatal error:  Allowed memory size of XXXXXX bytes exhausted <...>`
+
+In this case, the PHP `memory_limit` should be increased.
+
+> **Note:** Composer internally increases the `memory_limit` to `1.5G`.
+
+To get the current `memory_limit` value, run:
+
+```sh
+php -r "echo ini_get('memory_limit').PHP_EOL;"
+```
+
+Try increasing the limit in your `php.ini` file (ex. `/etc/php5/cli/php.ini` for
+Debian-like systems):
+
+```ini
+; Use -1 for unlimited or define an explicit value like 2G
+memory_limit = -1
+```
+
+Composer also respects a memory limit defined by the `COMPOSER_MEMORY_LIMIT` environment variable:
+
+```sh
+COMPOSER_MEMORY_LIMIT=-1 composer.phar <...>
+```
+
+Or, you can increase the limit with a command-line argument:
+
+```sh
+php -d memory_limit=-1 composer.phar <...>
+```
+
+This issue can also happen on cPanel instances, when the shell fork bomb protection is activated. For more information, see the [documentation](https://documentation.cpanel.net/display/68Docs/Shell+Fork+Bomb+Protection) of the fork bomb feature on the cPanel site.
+
+## Xdebug impact on Composer
+
+To improve performance when the xdebug extension is enabled, Composer automatically restarts PHP without it.
+You can override this behavior by using an environment variable: `COMPOSER_ALLOW_XDEBUG=1`.
+
+Composer will always show a warning if xdebug is being used, but you can override this with an environment variable:
+`COMPOSER_DISABLE_XDEBUG_WARN=1`. If you see this warning unexpectedly, then the restart process has failed:
+please report this [issue](https://github.com/composer/composer/issues).
+
+## "The system cannot find the path specified" (Windows)
+
+1. Open regedit.
+2. Search for an `AutoRun` key inside `HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor`,
+   `HKEY_CURRENT_USER\Software\Microsoft\Command Processor`
+   or `HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Command Processor`.
+3. Check if it contains any path to non-existent file, if it's the case, remove them.
+
+## API rate limit and OAuth tokens
+
+Because of GitHub's rate limits on their API it can happen that Composer prompts
+for authentication asking your username and password so it can go ahead with its work.
+
+If you would prefer not to provide your GitHub credentials to Composer you can
+manually create a token using the following procedure:
+
+1. [Create](https://github.com/settings/tokens) an OAuth token on GitHub.
+[Read more](https://github.com/blog/1509-personal-api-tokens) on this.
+
+2. Add it to the configuration running `composer config -g github-oauth.github.com <oauthtoken>`
+
+Now Composer should install/update without asking for authentication.
+
+## proc_open(): fork failed errors
+If composer shows proc_open() fork failed on some commands:
+
+`PHP Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar`
+
+This could be happening because the VPS runs out of memory and has no Swap space enabled.
+
+```sh
+free -m
+
+total used free shared buffers cached
+Mem: 2048 357 1690 0 0 237
+-/+ buffers/cache: 119 1928
+Swap: 0 0 0
+```
+
+To enable the swap you can use for example:
+
+```sh
+/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
+/sbin/mkswap /var/swap.1
+/sbin/swapon /var/swap.1
+```
+You can make a permanent swap file following this [tutorial](https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04).
+
+## Degraded Mode
+
+Due to some intermittent issues on Travis and other systems, we introduced a
+degraded network mode which helps Composer finish successfully but disables
+a few optimizations. This is enabled automatically when an issue is first
+detected. If you see this issue sporadically you probably don't have to worry
+(a slow or overloaded network can also cause those time outs), but if it
+appears repeatedly you might want to look at the options below to identify
+and resolve it.
+
+If you have been pointed to this page, you want to check a few things:
+
+- If you are using ESET antivirus, go in "Advanced Settings" and disable "HTTP-scanner"
+  under "web access protection"
+- If you are using IPv6, try disabling it. If that solves your issues, get in touch
+  with your ISP or server host, the problem is not at the Packagist level but in the
+  routing rules between you and Packagist (i.e. the internet at large). The best way to get
+  these fixed is raise awareness to the network engineers that have the power to fix it.
+  Take a look at the next section for IPv6 workarounds.
+
+- If none of the above helped, please report the error.
+
+## Operation timed out (IPv6 issues)
+
+You may run into errors if IPv6 is not configured correctly. A common error is:
+
+```
+The "https://getcomposer.org/version" file could not be downloaded: failed to
+open stream: Operation timed out
+```
+
+We recommend you fix your IPv6 setup. If that is not possible, you can try the
+following workarounds:
+
+**Workaround Linux:**
+
+On linux, it seems that running this command helps to make ipv4 traffic have a
+higher prio than ipv6, which is a better alternative than disabling ipv6 entirely:
+
+```bash
+sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"
+```
+
+**Workaround Windows:**
+
+On windows the only way is to disable ipv6 entirely I am afraid (either in windows or in your home router).
+
+**Workaround Mac OS X:**
+
+Get name of your network device:
+
+```bash
+networksetup -listallnetworkservices
+```
+
+Disable IPv6 on that device (in this case "Wi-Fi"):
+
+```bash
+networksetup -setv6off Wi-Fi
+```
+
+Run composer ...
+
+You can enable IPv6 again with:
+
+```bash
+networksetup -setv6automatic Wi-Fi
+```
+
+That said, if this fixes your problem, please talk to your ISP about it to
+try and resolve the routing errors. That's the best way to get things resolved
+for everyone.
+
+## Composer hangs with SSH ControlMaster
+
+When you try to install packages from a Git repository and you use the `ControlMaster`
+setting for your SSH connection, Composer might hang endlessly and you see a `sh`
+process in the `defunct` state in your process list.
+
+The reason for this is a SSH Bug: https://bugzilla.mindrot.org/show_bug.cgi?id=1988
+
+As a workaround, open a SSH connection to your Git host before running Composer:
+
+```bash
+ssh -t git@mygitserver.tld
+composer update
+```
+
+See also https://github.com/composer/composer/issues/4180 for more information.
+
+## Zip archives are not unpacked correctly.
+
+Composer can unpack zipballs using either a system-provided `unzip` utility or PHP's
+native `ZipArchive` class. The `ZipArchive` class is preferred on Windows. On other
+OSes where ZIP files can contain permissions and symlinks, the `unzip` utility is
+preferred. You're advised to install it if you need these features.

data/helpers/vendor/composer/composer/doc/articles/vendor-binaries.md

@@ -0,0 +1,110 @@
+<!--
+    tagline: Expose command-line scripts from packages
+-->
+
+# Vendor binaries and the `vendor/bin` directory
+
+## What is a vendor binary?
+
+Any command line script that a Composer package would like to pass along
+to a user who installs the package should be listed as a vendor binary.
+
+If a package contains other scripts that are not needed by the package
+users (like build or compile scripts) that code should not be listed
+as a vendor binary.
+
+## How is it defined?
+
+It is defined by adding the `bin` key to a project's `composer.json`.
+It is specified as an array of files so multiple binaries can be added
+for any given project.
+
+```json
+{
+    "bin": ["bin/my-script", "bin/my-other-script"]
+}
+```
+
+## What does defining a vendor binary in composer.json do?
+
+It instructs Composer to install the package's binaries to `vendor/bin`
+for any project that **depends** on that project.
+
+This is a convenient way to expose useful scripts that would
+otherwise be hidden deep in the `vendor/` directory.
+
+## What happens when Composer is run on a composer.json that defines vendor binaries?
+
+For the binaries that a package defines directly, nothing happens.
+
+## What happens when Composer is run on a composer.json that has dependencies with vendor binaries listed?
+
+Composer looks for the binaries defined in all of the dependencies. A
+symlink is created from each dependency's binaries to `vendor/bin`.
+
+Say package `my-vendor/project-a` has binaries setup like this:
+
+```json
+{
+    "name": "my-vendor/project-a",
+    "bin": ["bin/project-a-bin"]
+}
+```
+
+Running `composer install` for this `composer.json` will not do
+anything with `bin/project-a-bin`.
+
+Say project `my-vendor/project-b` has requirements setup like this:
+
+```json
+{
+    "name": "my-vendor/project-b",
+    "require": {
+        "my-vendor/project-a": "*"
+    }
+}
+```
+
+Running `composer install` for this `composer.json` will look at
+all of project-a's binaries and install them to `vendor/bin`.
+
+In this case, Composer will make `vendor/my-vendor/project-a/bin/project-a-bin`
+available as `vendor/bin/project-a-bin`. On a Unix-like platform
+this is accomplished by creating a symlink.
+
+## What about Windows and .bat files?
+
+Packages managed entirely by Composer do not *need* to contain any
+`.bat` files for Windows compatibility. Composer handles installation
+of binaries in a special way when run in a Windows environment:
+
+ * A `.bat` file is generated automatically to reference the binary
+ * A Unix-style proxy file with the same name as the binary is generated
+   automatically (useful for Cygwin or Git Bash)
+
+Packages that need to support workflows that may not include Composer
+are welcome to maintain custom `.bat` files. In this case, the package
+should **not** list the `.bat` file as a binary as it is not needed.
+
+## Can vendor binaries be installed somewhere other than vendor/bin?
+
+Yes, there are two ways an alternate vendor binary location can be specified:
+
+ 1. Setting the `bin-dir` configuration setting in `composer.json`
+ 1. Setting the environment variable `COMPOSER_BIN_DIR`
+
+An example of the former looks like this:
+
+```json
+{
+    "config": {
+        "bin-dir": "scripts"
+    }
+}
+```
+
+Running `composer install` for this `composer.json` will result in
+all of the vendor binaries being installed in `scripts/` instead of
+`vendor/bin/`.
+
+You can set `bin-dir` to `./` to put binaries in your project root.

data/helpers/vendor/composer/composer/doc/articles/versions.md

@@ -0,0 +1,230 @@
+<!--
+    tagline: Versions explained.
+-->
+
+# Versions and constraints
+
+## Composer Versions vs VCS Versions
+
+Because Composer is heavily geared toward utilizing version control systems
+like git, the term "version" can be a little ambiguous. In the sense of a
+version control system, a "version" is a specific set of files that contain
+specific data. In git terminology, this is a "ref", or a specific commit,
+which may be represented by a branch HEAD or a tag. When you check out that
+version in your VCS -- for example, tag `v1.1` or commit `e35fa0d` --, you're
+asking for a single, known set of files, and you always get the same files back.
+
+In Composer, what's often referred to casually as a version -- that is,
+the string that follows the package name in a require line (e.g., `~1.1` or
+`1.2.*`) -- is actually more specifically a version constraint. Composer
+uses version constraints to figure out which refs in a VCS it should be
+checking out (or simply to verify that a given library is acceptable in
+the case of a statically-maintained library with a `version` specification
+in `composer.json`).
+
+## VCS Tags and Branches
+
+*For the following discussion, let's assume the following sample library
+repository:*
+
+```sh
+~/my-library$ git branch
+v1
+v2
+my-feature
+nother-feature
+
+~/my-library$ git tag
+v1.0
+v1.0.1
+v1.0.2
+v1.1-BETA
+v1.1-RC1
+v1.1-RC2
+v1.1
+v1.1.1
+v2.0-BETA
+v2.0-RC1
+v2.0
+v2.0.1
+v2.0.2
+```
+
+### Tags
+
+Normally, Composer deals with tags (as opposed to branches -- if you don't
+know what this means, read up on
+[version control systems](https://en.wikipedia.org/wiki/Version_control#Common_vocabulary)).
+When you write a version constraint, it may reference a specific tag (e.g.,
+`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 list
+all available tags, then creates an internal list of available versions based
+on these tags. In the above example, composer's internal list includes versions
+`1.0`, `1.0.1`, `1.0.2`, the beta release of `1.1`, the first and second
+release candidates of `1.1`, the final release version `1.1`, etc.... (Note
+that Composer automatically removes the 'v' prefix in the actual tagname to
+get a valid final version number.)
+
+When Composer has a complete list of available versions from your VCS, it then
+finds the highest version that matches all version constraints in your project
+(it's possible that other packages require more specific versions of the
+library than you do, so the version it chooses may not always be the highest
+available version) and it downloads a zip archive of that tag to unpack in the
+correct location in your `vendor` directory.
+
+### Branches
+
+If you want Composer to check out a branch instead of a tag, you need to point it to the branch using the special `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](../03-cli.md#install).)
+
+In the above example, if you wanted to check out the `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.
+
+When branch names look like versions, we have to clarify for composer that we're trying to check out a branch and not a tag. In the above example, we have two version branches: `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.
+
+### Minimum Stability
+
+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 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.
+
+### Exact Version Constraint
+
+You can specify the exact version of a package. This will tell Composer to
+install this version and this version only. If other dependencies require
+a different version, the solver will ultimately fail and abort any install
+or update procedures.
+
+Example: `1.0.2`
+
+### Version Range
+
+By using comparison operators you can specify ranges of valid versions. Valid
+operators are `>`, `>=`, `<`, `<=`, `!=`.
+
+You can define multiple ranges. Ranges separated by a space (<code>&nbsp;</code>)
+or comma (`,`) will be treated as a **logical AND**. A double pipe (`||`)
+will be treated as a **logical OR**. AND has higher precedence than OR.
+
+> **Note:** Be careful when using unbounded ranges as you might end up
+> unexpectedly installing versions that break backwards compatibility.
+> Consider using the [caret](#caret-version-range-) operator instead for safety.
+
+Examples:
+
+* `>=1.0`
+* `>=1.0 <2.0`
+* `>=1.0 <1.1 || >=1.2`
+
+### Hyphenated Version Range ( - )
+
+Inclusive set of versions. Partial versions on the right include are completed
+with a wildcard. For example `1.0 - 2.0` is equivalent to `>=1.0.0 <2.1` as the
+`2.0` becomes `2.0.*`. On the other hand `1.0.0 - 2.1.0` is equivalent to
+`>=1.0.0 <=2.1.0`.
+
+Example: `1.0 - 2.0`
+
+### Wildcard Version Range (.*)
+
+You can specify a pattern with a `*` wildcard. `1.0.*` is the equivalent of
+`>=1.0 <1.1`.
+
+Example: `1.0.*`
+
+## Next Significant Release Operators
+
+### Tilde Version Range (~)
+
+The `~` 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 see
+it is mostly useful for projects respecting [semantic
+versioning](https://semver.org/). A common usage would be to mark the minimum
+minor version you depend on, like `~1.2` (which allows anything up to, but not
+including, 2.0). Since in theory there should be no backwards compatibility
+breaks 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.
+
+Example: `~1.2`
+
+> **Note:** Although `2.0-beta.1` is strictly before `2.0`, a version constraint
+> like `~1.2` would not install it. As said above `~1.2` only means the `.2`
+> can change but the `1.` part is fixed.
+
+> **Note:** The `~` operator has an exception on its behavior for the major
+> release number. This means for example that `~1` is the same as `~1.0` as
+> it will not allow the major number to increase trying to keep backwards
+> compatibility.
+
+### Caret Version Range (^)
+
+The `^` operator behaves very similarly but it sticks closer to semantic
+versioning, 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 should
+break backwards compatibility. For pre-1.0 versions it also acts with safety
+in mind and treats `^0.3` as `>=0.3.0 <0.4.0`.
+
+This is the recommended operator for maximum interoperability when writing
+library code.
+
+Example: `^1.2.3`
+
+## Stability Constraints
+
+If you are using a constraint that does not explicitly define a stability,
+Composer will default internally to `-dev` or `-stable`, depending on the
+operator(s) used. This happens transparently.
+
+If you wish to explicitly consider only the stable release in the comparison,
+add the suffix `-stable`.
+
+Examples:
+
+ 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`
+
+To allow various stabilities without enforcing them at the constraint level
+however, you may use [stability-flags](../04-schema.md#package-links) like
+`@<stability>` (e.g. `@dev`) to let composer know that a given package
+can be installed in a different stability than your default minimum-stability
+setting. All available stability flags are listed on the minimum-stability
+section of the [schema page](../04-schema.md#minimum-stability).
+
+## Summary
+```json
+"require": {
+    "vendor/package": "1.3.2", // exactly 1.3.2
+
+    // >, <, >=, <= | specify upper / lower bounds
+    "vendor/package": ">=1.3.2", // anything above or equal to 1.3.2
+    "vendor/package": "<1.3.2", // anything below 1.3.2
+
+    // * | wildcard
+    "vendor/package": "1.3.*", // >=1.3.0 <1.4.0
+
+    // ~ | allows last digit specified to go up
+    "vendor/package": "~1.3.2", // >=1.3.2 <1.4.0
+    "vendor/package": "~1.3", // >=1.3.0 <2.0.0
+
+    // ^ | doesn't allow breaking changes (major version fixed - following semver)
+    "vendor/package": "^1.3.2", // >=1.3.2 <2.0.0
+    "vendor/package": "^0.3.2", // >=0.3.2 <0.4.0 // except if major version is 0
+}
+```
+
+## Testing Version Constraints
+
+You can test version constraints using [semver.mwl.be](https://semver.mwl.be).
+Fill in a package name and it will autofill the default version constraint
+which Composer would add to your `composer.json` file. You can adjust the
+version constraint and the tool will highlight all releases that match.