Why drop php 7.2 support?

[MarkVaughn]

Why did you drop php 7.2 support?
https://www.php.net/supported-versions.php 7.2 is still actively supported. This package is a dependency from phpstan and is breaking a lot of builds.

[Ocramius]

Hey there,

I dropped 7.2 because newer releases are meant for current stable (7.3).

Besides that, previous releases work just as fine 👍

PHPStan pins to jean85/pretty-package-versions:^1.0.3, which locks onto "ocramius/package-versions": "^1.2.0"

That means that your composer update should work as fine on PHP 7.1, PHP 7.2 or PHP 7.3.

[Ocramius]

and is breaking a lot of builds.

I'd check those builds: you are likely running composer update and composer install on respectively incompatible environments.

[MarkVaughn]

I don't understand why the composer update uses version 1.5.1 instead of the locked version.

[Ocramius]

@MarkVaughn if you run composer update on a machine with PHP 7.3, that's perfectly normal.

[MarkVaughn]

I see the dev environment is 7.3 but the Docker images and Travis ci are 7.2

[Ocramius]

You should tun composer update in your docker environment then 👍

[kevinpapst]

@MarkVaughn I tripped into the same problem, but not with a dev dependency:

$ composer why ocramius/package-versions
doctrine/migrations             v2.1.0  requires  ocramius/package-versions (^1.3)    
jean85/pretty-package-versions  1.2     requires  ocramius/package-versions (^1.2.0)  
ocramius/proxy-manager          2.1.1   requires  ocramius/package-versions (^1.1.1) 

Using a platform in your composer helps to prevent that problem in the future:

    "config": {
        "platform": {
            "php": "7.2"
        },
    },

A composer update will perform a downgrade with that:

Downgrading ocramius/package-versions (1.5.1 => 1.4.0): Loading from cache

[cleptric]

@Ocramius Would you please consider releasing a new major if you make backwards compatibility breaking changes in the future? 🙂

[Ocramius]

A bump in dependencies is not a BC break if the API signature and behavior of the library does not change due to those dependency upgrades.

• See https://github.com/semver/semver/blob/d460299638d3d2af6fcf809285dc6a469e15742a/semver.md#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api
• See https://www.doctrine-project.org/2017/07/25/php-7.1-requirement-and-composer.html

[MarkVaughn]

If nothing changed why bump dependencies when 7.2 is still active supported?

[Ocramius]

I bump to latest release of all dependencies whenever I can

[kevinpapst]

@Ocramius don't get me wrong, your repo your rules!
And actually I don't mind, its easy to workaround... but I just wonder: this package is at least a second-level dependency in thousands of projects (>22 million installations is a lot) and many of us will have to support 7.2 for some time. Through that dependency tree and support for 7.2 many apps relying on the large frameworks won't be able to benefit from all your coming fixes/improvements, won't they?!

[Ocramius]

Correct: they will have to upgrade dependencies. Besides that, 1.4.x works just fine

[drewjoh]

Just to add some feedback: This has bitten me also. PackageVersions is a second (or third or fourth?) level dependency which I don't control. We use Semaphore CI for testing before deployment, and Semaphore only supports up to PHP version 7.2.9 at this moment.

I've spent several hours already trying to see about manually having the build install the latest PHP in Semaphore, to no avail... so our CICD pipeline is now out of commission at the moment until we find a solution.

As others have noted, really appreciate your work in the community. This is just feedback & another data point. Thanks!

[Ocramius]

We use Semaphore CI for testing before deployment, and Semaphore only supports up to PHP version 7.2.9 at this moment.

If your CI is testing an environment that isn't production, your CI is indeed to be replaced. CI runs must be much closer to production runs, and it is a good thing that this package highlighted the issue in your CI setup.

To clarify for further readers (because I'm locking the thread):

Run composer update only in production-compatible systems

You MUST run composer update on a system that supports your target deployment environment(s): no escape from that. This is imperative (that's the "MUST" in the sentence)!
If you don't do that, you are really (really!) doing it wrong.

This holds true since composer 1.0.0-alpha1, released 8 years ago, and is at the core of the design of the composer.lock mechanism.

• See also "so you want to write a package manager"
• See also why dependency upgrades are not BC breaks
• See also workaround to "enforce" system dependencies in composer.json, if you don't have a production-alike dev environment (avoid, if possible)

Upgrades to dependencies SHOULD and WILL be performed in all my packages at the earliest occurrence!