+composer.lock

[simPod]

Following discussion from https://github.com/liuggio/fastest/pull/94

I believe composer.lock should be versioned for the reasons I mentioned there

[DonCallisto]

I've seen many other OOS project and I never found composer.lock committed. Could you investigate deeply and report your motivation along with other OOS that includes composer.lock?

Thanks for the collaboration.

[simPod]

Didn't find any. However, didn't dedicated a few minutes to it either. :D

Composer states in docs this:

For your library you may commit the composer.lock file if you want to. This can help your team to always test against the same dependency versions. However, this lock file will not have any effect on other projects that depend on it. It only has an effect on the main project.

It is not necessary but I think it keeps the consistency.

If you decide to close this, I won't be mad ;) . But I have said everything I could on this topic though.

[DonCallisto]

I'm not for closing or rejecting this, I'm just wondering what's the best for the project. Let's keep this open with "help wanted" and see if anyone bring any idea for one or the other approach.

Do you agree?

[simPod]

Sure, np

[DonCallisto]

/cc @liuggio (when you have time we would like to have your two cents also) 👍

[simPod]

I have not found any library versioning composer.lock recently

[DonCallisto]

@simPod yesterday I read this and this but I still have no idea about the best way to handle lock file.

[francoispluchino]

@DonCallisto As with any lock file, the composer.lock file is used to lock the versions of installed dependencies, thus ensuring that the tests executed will always be carried out with the same versions of dependencies. For example: you using Travis-CI, and a new version of a dependency might be available between your local tests and the tests on Travis, and so, throws an exception on Travis while everything is ok locally. Locking helps prevent these problems.

It is recommended that you include the composer.lock file in your VCS, and commit the changes to each dependencies update.

The post Composer: It's All About the Lock File will explain you better than I do.

[alexislefebvre]

@francoispluchino These arguments are valid for a project. I still think that running tests with fixed versions (because of composer.lock) while users install this package as a dependency is not logical. The projects that require this project won't use the composer.lock so projects will have newer versions of other libraries.

[DonCallisto]

I strongly agree with @alexislefebvre

To me is better to stay without composer.lock as it is now.