gRegorLoveIn general, I'm in favor of the minimal necessary changes to make it PHP5.6 minimum. I'm not aware of the .lock file causing problems to date.
[jgarber]Are there any objections to merging these two PRs on microformats/tests? [jansauer] and I have reviewed one another’s, but would anyone else care to chime in?
cjw6kThe composer.lock file takes the set of dependencies, and puts a single pin/thread through each one that strings together a working valid state. It may bite hard in future days when composer.lock is missing.
cjw6kGiven dependencies A and B which each depend on a dependency P: at some future date P pushes a new major version. Dependency A updates to require D at the new major version, but may not update it's own major version number. Meanwhile B continues but isn't ready to change to meet requires for the new major release of P.
cjw6kWithout a lock file, composer tries to resolve the dependency issues automatially. In a perfect scenario, composer would collapse these conflicts into a working set of dependencies.
cjw6kIt doesn't always work like this in practice. Composer balloons to use a very, very large amount of RAM while chasing a working combination of packages. Consider a 2GB of RAM virtual machine not having enough memory for the process to complete.
cjw6kThe composer.lock file permits the install to choose the exact versions of dependencies which provide a working state and avoids the whole ordeal.
cjw6kIt's a simple enough process to resolve this irreconcilable dependency issue with composer, but it takes specialized knowledge and a very good grasp the cause of the error.
GWGI'm still not 100% versed in how you generate a lock file for a specific PHP version other than adding the config parameter, generating it then removing the config parameter
gRegorLoveIt's what GWG ran into in the earlier commits. The dependencies he added used PHP7-compatible versions bc his PHP env was 7. Then Travis failed on PHP5.6