New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keep composer.json and composer.lock synchronised at all times #6058
Comments
Is there something still to do? Shouldn't we still possible to define versions like ">= 3.4.0" as long as we always commit the composer.lock file? |
It might be causing a BC breaks for older versions. I.e - in Piwik 2.5.0 there is some certain version of library in composer.lock (which contains exact commit mark), and >= 1.0.0 in composer.json . After version bump of this single library installation from composer.lock will still work fine, while installing as dependency will fail (newer version would be cloned). |
I think I got it! Or maybe not... Shoudn't "composer install" prevent exactly this? I thought composer.lock always saves a fixed version number and as long as someone is not using "composer update" everything should be fine? Even for older versions of Piwik and even if there is a new version of a used library.
Jog my memory. I'm usually not installing it as a dependency therefore I need a helping hand ;) |
@mgazdzik is there still something to do? |
@tsteur - sorry for late reply, I didin't notice your previous comment before. As far as I remember, when downloading Piwik as dependency - composer.lock file is simply not even parsed by main composer, only dependencies from composer.json are being downloaded according to its constraints. Please let me know if this explaination is sufficient or you would like me to reffer to some documentation (currently I'm speaking basing on experience) |
OK, so the conclusion is that we have to specify exact version numbers in composer.json? Wondering how we still can get updates without having to check for updates manually. |
Here is the current "require": {
"php": ">=5.3.3",
"twig/twig": "1.*",
"leafo/lessphp": "0.4",
"symfony/console": ">=v2.3.5",
"tedivm/jshrink": "v0.5.1",
"mustangostang/spyc": "0.5.*",
"piwik/device-detector": "2.*",
"piwik/decompress": "~0.1.0"
} What we could do is strengthen the version constraints so that we minimize the risks of BC breaks in dependencies. Putting exact version numbers in there (like If, for a library, we can safely assume that there will be no BC breaks between patch releases (semver enforced), then we could use version constraints like this for every dependency: What we must not do is:
About Anyway, here is a suggestion: "require": {
"php": ">=5.3.3",
"twig/twig": "~1.0",
"leafo/lessphp": "~0.4.0",
"symfony/console": "~2.3",
"tedivm/jshrink": "~0.5.1",
"mustangostang/spyc": "~0.5.0",
"piwik/device-detector": "~2.0",
"piwik/decompress": "~0.1.0"
} TL/DR:
|
sounds good |
@mnapoli yeah, sounds good to me as well. We should be all good as long as we provide strict enoguh constraints to avoid situations like in this PR https://github.com/piwik/piwik/pull/6043/files |
Updated composer constraints for #6058
The pull request has been merged. |
Due to possibility of using Piwik as dependency (i.e. for automating build and deploy process) it would be great to keep those 2 files synchronised at all times, and in specific it involves using strict versioning in composer.json to avoid uncontrolled version switches which could break deployment procedure.
The text was updated successfully, but these errors were encountered: