Remove composer.lock file

[Ocramius]

As per current dependencies, the project is quite broken.

I suggest dropping composer.lock so that the build process can expose that as soon as a breakage in the dependency versions happens

[mvriel]

Can you indicate which version that you use? (a tag or branch)

Also: dropping the composer.lock means that when a build breaks that we cannot be sure that the breakage is introduced by a change or upstream that chooses to broke SEMVER. The lock file is a prescription of a guaranteed major.minor.build that we can support.

What I would like is a monitoring system that runs unit tests whenever a dependency publishes a new version that falls within the version range. But since there is no service that currently offers that I will have to spend some time for that soon :)

[Ocramius]

dropping the composer.lock means that when a build breaks that we cannot be sure that the breakage is introduced by a change or upstream that chooses to broke SEMVER.

That's what the build is for anyway: consumers of the package may be affected by such a case anyway, so we are just weakening stability by not catching these mistakes upfront.

Linking thephpleague/tactician#6 to not repeat myself ;-)

What I would like is a monitoring system that runs unit tests whenever a dependency publishes a new version that falls within the version range. But since there is no service that currently offers that I will have to spend some time for that soon :)

That's actually a very good suggestion!

[mvriel]

I agree with you that a mechanism should be present to check if versions of dependencies outside of the information in the lock file should be checked. In my opinion omitting the lock file is not that mechanism however since you rely on your commit frequency to test new versions of dependencies and pollute your CI setup as I consider that is meant to catch regression issues and not whether new versions of upstream packages.

So imo: yes, this should be caught but removing the lock file is counter intuitive to the CI process

[mvriel]

Corrollary: I will re-add the update step to travis; what we previously did was run the build by first running the unit tests against the packages in the lock file, then update the packages and re-run the unit tests. This will serve both purposes I think

[ashnazg]

I was just about to suggest exactly this :-) On Jun 26, 2015 5:40 AM, "Mike van Riel" notifications@github.com wrote:

Corrollary: I will re-add the update step to travis; what we previously did was run the build by first running the unit tests against the packages in the lock file, then update the packages and re-run the unit tests. This will serve both purposes I think

— Reply to this email directly or view it on GitHub https://github.com/phpDocumentor/Reflection/issues/67#issuecomment-115638442 .

[Ocramius]

That could work indeed :-)

[mvriel]

The Reflection, ReflectionDocBlock and TypeResolver repositories have been updated with this setup