@mgazdzik asked the same question several times and nothing has changed so I'd say that the answer is no (even though it would make my life easier as well).

The answer in the screenshot (the one from Josh) is out of topic as long as you use composer install instead of composer update (which is the recommended practice). This is a common mistake, nobody should run composer update unless they actually want to update a dependency. The answer from "jieg" says:

For application/projects: Yes

Piwik is an application, not a library, so yes we should commit composer.lock (which is what we are doing). I don't see why we should move away from that.

I don't see a reason to use fixed versions, and see the following downsides:

• sometimes we require specific versions because of a specific reasons: in that case we can see it in composer.json and be very careful when updating the version (because we can't add comments in JSON) -> so that's useful to be able to use ~2.1 and in other places 1.4.4
• we risk updating the versions even less because it's one more step (edit composer.json + run composer update) -> the simpler the workflow is, the better IMO (i.e. just running composer update thepackage is good)

Also keep in mind that the good practice of Composer is to commit the composer.lock file for applications (which we are doing). So I'd say it's good to stay with the official best practices.

On the other side, I don't see problems with the current practice (but maybe there are). Could you please list them?

@mnapoli There was a problem for me to use some custom vendors that I added in composer.json, and getting conflict in Git switching to different branches.

Matt, thanks for your answer - it's very good explanation of how it works for Piwik.

It's still open for discussion though if we have particular issues. But your conflicts with composer.json will still be there even if we use fixed version numbers (as this file will stay committed anyway).

@mnapoli Problem is that modified composer.lock can't be merged automatically with composer.lock of another branch. Merging composer.json when switching between branches works fine.

Versionning composer.lock in your project avoids a large memory load on the server. composer uses lots of memory when calculating dependencies, but not when just installing packages.