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.

If there is a composer.lock file in the current directory, it will use the exact versions from there instead of resolving them. This ensures that everyone using the library will get the same versions of the dependencies.

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 composer.json:

    "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 "tedivm/jshrink": "v0.5.1") is going a bit too far IMO (unless there's a good reason). We will fall behind new versions too fast and too far.

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: 2.1.* (or ~2.1.0 which is roughly the same). Eg Symfony commit to "no BC breaks for minors" so we could use ~2.3.

What we must not do is:

• >=v2.3.5 because when 3.0.0 gets out it will be installed!
• v0.5.1 unless there is no good reason. When I look at the project I read: v0.5.2: The JShrink code itself is unchanged, and you should be able to update without issue. I also see he released a v1.0.0, so we should consider updating when we get some time to review.

About "twig/twig": "1.*" are we sure twig keeps BC between minors?

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:

• ~1.0 for packages following semver strictly because it shouldn't break between minors
• ~1.0.0 for other packages because patch releases should have a very low risk of BC breaks

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

The pull request has been merged.