Reputation: 9546
We have composite project with many custom and 3rd party libraries. We are looking for a way to update most of the sub project with composer update.. but to be safe, we need to lock down all the sub dependencies to the currently installed version.
I had no problems with tagged versions, but "dev-master" gives me trouble
can a Lock a dependencies "some/fu" : "dev-master"
(with current version 0.1) to stay as it is, and never update to 0.2 ?
Upvotes: 1
Views: 325
Reputation: 10185
In addition to @Peh answer:
Yes, using dev-master
is a bad practice. But if it is a really necessary you can pick up certain commit "symfony/finder": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e"
What scenario does lead to problems with master
branch? when do you want execute composer update
?
Upvotes: 0
Reputation: 57683
The problem is that dev-master
is a moving target. So the meaning of dev-master
can change at any time.
Let's say that it represents the latest 1.0 development version. At some point the author of said library starts working on the 1.1
release, so they branch off a 1.0
branch, and dev-master
becomes automatically the latest 1.1
dev version.
Technically the dev-master
has no version it is a version and it represents the most current development state of the master branch.
If you have control over the source repository which you want to require you could make use of a branch alias.
Or you can update only specific packages like composer update vendor/package1 vendor/package2
or to shorten it specific vendors composer update vendor/*
instead of a full composer update
. As far as I know there is no possibility to exclude specific packages from update yet.
Upvotes: 2