Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Maintaining Package Versions3:40 with Alena Holligan
Composer plays an important role in package versioning. This versioning is built around a standard versioning system called Semantic Versioning, allowing you to stay current on security updates and upgrade as new features become available.
Testing Version Constraints
There is a handy packagist semver checker (short for symantic versioning) that allows you to test out your version constraints.
Version Usage Documentation
Exact - 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.
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 ( ) 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 operator instead for safety.
>=1.0 >=1.0 <2.0 >=1.0 <1.1 || >=1.2*
Range (Hyphen) - 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.
1.0 - 2.0
Wildcard - You can specify a pattern with a * wildcard. 1.0.* is the equivalent of >=1.0 <1.1.
Next Significant Release Operators
Tilde - 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. 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.
Caret - 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.
Composer plays another important role by helping us maintain package versioning.
This feature has a couple important benefits.
First, it allows us to stay current on any security updates
to external packages that we're using in our application.
Second, it allows us to easily upgrade as new features become available.
So how does versioning work and how do we use composer to maintain versioning?
Composer version control is built around a standard versioning system
called semantic versioning.
Under this system, version numbers and the way they change convey meaning about
the underlying code and what has been modified from one version to the next.
The first position signifies major changes
that break the way things work in the previous version.
The second position signifies minor changes such as new features that
add functionality without changing current functionality.
And finally, the third position signifies patches such as bug fixes or
Incrementing on any of these numbers signifies a change.
Let's take P.H.P. for example in September of
2016 P.H.P. released version 7.0.11.
7 stands for the major version,
0 is the minor version, and 11 is the current patch.
As a general rule, upgrading to a minor release or patch within the same
major release should be backwards compatible and not break any of your code.
This standard is widely accepted,
however, not every package you use is guaranteed to follow these guidelines.
So it's a good idea to check with the package you wish to use.
Let's now go see package versioning in action with composer.
Let's start by taking a look at what we already have.
We use the command line to install packages up to this point.
Composer uses a composer.json file for configuration and
you can modify this file manually.
When we open the file, you can see the four packages we installed, but
not their dependencies.
Composer handles the package dependencies for us.
You can add, remove and change packages and versions directly in this file.
Next to each package is a version number.
Notice how they only have two positions and there is a carrot at the beginning.
This defines the minimum required version and
allows composer to perform any minor or patch updates.
This also prevents composer from upgrading to the next major version.
Composer gives you many different options for controlling versions.
For example, I can change the caret to a Tilde in the HTML purifier.
I get the same results because using a tilde will increment
the last number given.
However, if I specify tilde 4.8.0,
it would only increment the patch version.
While using caret 4 .8.0 will increment both the patch and the minor version.
Check out the notes associated with this video
to learn more about options and tools.
When you make changes to your composer.json file,
those changes will not take effect until you run a composer update.
You need to sign up for Treehouse in order to download course files.Sign up