Relying on A Dev-Master Dependency in Composer
If your project installation instructions recommend requiring dev-master in composer, I may need to reconsider my choice of package
— Lorna Mitchell (@lornajane) December 2, 2015
I got a few responses asking me to expand so I thought I would take the opportunity to write more than 140 characters on this topic.
When adding a dependency to my system, I will always try to pick one that is installable via Composer (these days, basically every project can be installed this way). However if you see in the installation instructions that you should use version "dev-master"
– that means that you’ll always install whatever is currently on the tip of the master branch in this project. There’s a vanishingly small number of situations where I’d want to do that. They are:
- This code is internal to an organisation, and is common to more than one project but not used by any external people so it is possible to track this dependency
- I’m depending on my own fork of something for a good reason (and even then it would not be the master branch, but it would be the tip of a potentially evolving branch rather than a reliable release so it’s still kind of the same)
- The package is special in some way and *should* release as many updates to me as humanly possible, such as https://github.com/Roave/SecurityAdvisories
Outside of these possibilities, if your project doesn’t have a named release I can only assume that either it is so alpha that I probably don’t want it in my project anyway* or that you don’t actually know how to tag a release for packagist (in which case, I doubt your wider technical abilities, sorry).
In summary: check your composer.json
files for "dev-master"
entries and replace them with an appropriate expression which includes your current version (see https://getcomposer.org/doc/articles/versions.md). This means that you won’t get unexpected updates that might be breaking changes, but you can safely upgrade within your specified versions. To find out what version you currently have, look for the package in your composer.lock
file as it will say what’s currently installed .
* another exceptional circumstance is where I expect to contribute to or at least follow closely the development of a very new tool, in which case I’ll accept the risks involved!
Use “composer show -i” for a nicer view of the currently installed versions better than look in the composer.lock.
An easier way to find what version of a library is installed: [code]composer show -i[/code]
Ah, beaten to the punch… the above comment didn’t show for me!
Or to get a required hotfix before it gets tagged to a release. Which at that point you have to remember to change it back.
I’m using dev-master with a Git commit hash in https://github.com/opdavies/oliverdavies.uk/blob/master/composer.json#L15, which seems to work for me. I get the latest commit of Sculpin, and the stability and reliability of knowing that it isn’t going to change without me being aware of it.
So I’ve checked composer for this, and found no packages using “dev-master”, but I’m still unsure what it would look like, are there examples of packages that do this?
Pingback: Using Composer with shared hosting | Rob Allen's DevNotes
I disagree. If the project has a composer.lock file then dev-master is fine. The point of the lock file is to record the exact versions that are installed so they can be re-installed exactly as is. If your project is tested and works with dev-master with a hash in the lock then that is the same thing as a tagged release.
More info:
https://blog.engineyard.com/2014/composer-its-all-about-the-lock-file
The mechanics work, certainly. My point is more about choosing the packages to include in your project and how a project’s lack of packaging might influence that
Pingback: PHP Annotated Monthly – January 2016 | PhpStorm Blog
Here is a good example where dev-master can come back to haunt you:
https://seld.be/notes/the-road-to-monolog-2-0
I agree with the comments above, there is no substitute for being careful and locking things down in composer.lock.