I recently tweeted this:
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!