Minimum PHP version change in minor is breaking dependents

[PeeHaa]

I am using phpunit on PHP 7.0.n. The last PHP version bump breaks this sebastianbergmann/phpunit-mock-objects#371

If we could not bump minimum PHP versions in minors that would be great. ❤️

[mikeSimonson]

http://doctrine-project.org/2017/07/25/php-7.1-requirement-and-composer.html

[PeeHaa]

k. But the fact of the matter is that it actually breaks stuff.

I very much strongly disagree with the Why dropping PHP support in a minor version is not a BC break statement.

I had code that works. And not it stops working. That's a breaking change.

From the page you linked:

For example, changing a method signature in a minor version is a no-go, since the composer version constraints mentioned above assume any minor upgrade can safely be used.

Bumping the PHP version resulted in exactly the same problem. It cannot be updated.

[Ocramius]

@PeeHaa dependency version bumps are not BC breaks. Also see https://github.com/mojombo/semver/blob/df7bd79bda7d7fe6da20d0724fe0111678cbaa8f/semver.md#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api

[Ocramius]

I had code that works. And not it stops working. That's a breaking change.

The code still works - you are just on the previous version of this particular dependency, as the SAT dependency solver of composer doesn't upgrade to a next minor. You will still get critical fixes in 1.0.x, should they occur.

[PeeHaa]

But they are. For my reasoning see the exact same discussion I had 2 weeks ago igorw/evenement#39.

The TL;DR is igorw/evenement#39 (comment)

The dependents do the right thing by targeting updates to at most minor which should not break things. Yet it breaks things.

[Ocramius]

@PeeHaa PHP's API is not our API - we are just depending on it as with any of the many dependencies or dev-dependencies of this package.

If you run 5.x, you will just get 1.0.x installed, according to SAT semantics.

[Ocramius]

The failure in question is caused by a composer.lock change that is incompatible with the travis environment. This kind of failure is expected and correct, as travis is emulating your "deployment environment", while a change was performed in a completely incompatible local environment.

This kind of error can happen in many scenarios:

• local environment older than production environment
• local environment newer than production environment
• local environment with different extensions than production environment

That's exactly what the composer.lock is designed for: preventing this sort of SNAFUs :-)

[PeeHaa]

FWIW I see what you people are doing (after a lengthy conversation with @Ocramius). I just don't agree with it and it will fail for more people :-)

Last thing you will ever hear me about this in this issue:

I cannot ship a .lock file anymore with my project so that:

• to ensure that the package versions are consistent for everyone working on your project

• it ensures that your project does not break because of unexpected changes in dependencies.

composer docs

_{Sorry for me keep going at it. I just can see the problems that come from this decision.}

Thanks for your patience o/

[Majkl578]

I just can see the problems that come from this decision.

The problem here is that people use Composer in a wrong way, not that PHP version requirement was bumped. We can just hope this will educate more people and they'll learn that using different versions on dev/ci/staging/production a dangerous idea...

[PeeHaa]

How can I make sure people downloading my project from github are installing the known and tested dependencies?

Everybody keep telling me I am composering wrong, but nobody can give me a sane solution for how to composer right when I want people to install the tested deps.

Now I am really done trying to convince people :-) I have heard and understood your side and I have said what I wanted.

[Ocramius]

You can't, because you tested it with specific environments and preset dependencies, and you don't control the user's environment. This is a very normal issue, and we discussed it. A `composer install` without lock file would probably resolve to the best possible set of dependencies when the deployment environment is unknown, but the risks are there.

…

On 1 Aug 2017 8:47 PM, "Pieter Hordijk" ***@***.***> wrote: How can I make sure people downloading my project from github and installing the known and tested dependencies? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakCuVmUMjcUCqFESQx4xt_oQEQ0dmks5sT3LYgaJpZM4Opze3> .

[lcobucci]

@PeeHaa as mentioned on the blog post you can define the platform on composer.json, this will make the resolver work properly.

[mikefrancis]

For anyone here having the same issue, I had developed a package on a PHP 7.1 box and our infrastructure is still running CI on 7.0, so Travis was failing.

To avoid a lengthy downgrade process and get around this, I did composer require doctrine/instantiator:~1.0.0.

Then you can either remove the dependency from your composer.json but only if you commit your lock file.

Edit: see @alcaeus comment below.

[alcaeus]

@mikefrancis or, alternatively, you don't commit a lock file that was generated on 7.1 if you're going to run code on 7.0. As suggested in the blog post, the correct way to handle these platform differences is by using the config.platform setting in composer.json, not arbitrarily restricting package versions.

[mikefrancis]

@alcaeus that's a much better solution

[Ocramius]

Locking single dependencies is also not the correct approach: if you know your deployment environment, lock onto that. Otherwise don't lock at all ( = you don't know the deployment system specifics)

[PeeHaa]

@alcaeus that only works sanely if there aren't any other packages pulling this same thing.

[alcaeus]

@PeeHaa platform.config is relevant on the root level. If somebody else pulls in your library, its their job to make sure the platform settings are correct, not yours.

[PeeHaa]

I don't have a library. I have a project.

[Ocramius]

We already discussed this: if you have a project, provide a lock file that works on all versions, or none at all if you cannot guarantee that.

…

On 2 Aug 2017 1:28 PM, "Pieter Hordijk" ***@***.***> wrote: I don't have a library. I have a project. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakB5HNPR1WTW7jJmmX9cFn4YagnRNks5sUF1pgaJpZM4Opze3> .

[PeeHaa]

I know. We already discussed. Just noting that said solution may not be a solution, because people refuse to see it for some reason. Anyway unsubbed from thread. Sorry for bothering you all :-)