1.4.0 without Composer 1 support should be a major release

Question

1.4.0 without Composer 1 support should be a major release

Closed this issue 4 years ago · 8 comments

Hi,

That release should be rather a major release: https://github.com/Jean85/pretty-package-versions/releases/tag/1.4.0

Packages such as sentry/sentry-symfony include "jean85/pretty-package-versions": "^1.0" which finally forces the installation of Jean85/pretty-package-versions 1.4.0 with dropped support for Composer 1.

We still need and have to use Composer 1.

Adding "jean85/pretty-package-versions": "1.3.0" explicitly to composer.json require section it solves issues meanwhile:
Package operations: 0 installs, 2 updates, 0 removals

Updating composer/package-versions-deprecated (1.8.0 => 1.8.0): Loading from cache
Downgrading jean85/pretty-package-versions (1.4.0 => 1.3.0): Loading from cache

Thanks
Rico

Answer 1 · 2020-05-06T13:24:01.000Z

No, that's not the case. Semantic Versioning says the opposite, and this has been reported in the same form (but for different dependencies) in Ocramius/PackageVersions#105 (comment)

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

You can continue to use Composer 1 without any issues. Only a minor issue in dependency resolve was fixed in Composer 1.10.6, see composer/composer#8846

Answer 2 · 2020-05-06T13:36:42.000Z

Yes, you are correct!

Nevertheless, I could solve the problem with my temp solution.

My problem is right now that https://github.com/heroku/heroku-buildpack-php only comes with Composer version 1.10.5 in the latest release. I will try to do a composer self-update during build.

Answer 3 · 2020-05-06T14:36:25.000Z

@RicoFactset And if you want to restrict package to both Composer 1.x and 2.x compatibility, avoid to hard-code with version 1.3.0, but use the tilde character as "jean85/pretty-package-versions": "~1.3" to limit versions less than equal 1.4

My Tip: I just did the same on one of my package today

Answer 4 · 2020-05-06T14:41:30.000Z

Thank you!

Answer 5 · 2020-05-06T14:57:48.000Z

Glad to help

Answer 6 · 2020-05-06T15:31:22.000Z

Actually, "jean85/pretty-package-versions": "~1.3" did not work for me. I had to do it this way: "jean85/pretty-package-versions": "1.3.0"

Answer 7 · 2020-05-06T16:48:03.000Z

If subpackages constraint jean85/pretty-package-versions (like you said ^1.0) then the only solution to fix it is to add in your root compose.json (file you have ability to change yourself) the constraint "~1.3", before the subpackage.

TIP: use this command composer why jean85/pretty-package-versions to learn who used this package, in your project

Answer 8 · 2020-05-07T07:08:21.000Z

TIP: use this command composer why jean85/pretty-package-versions to learn who used this package, in your project

That is unfortunately broken up until Composer 1.10.6 due to the issue I referenced above (composer/composer#8846), since jean85/pretty-package-versions 1.4 relies on a meta-package that declares the Composer API version.

Closing as it's fixed on Composer's side.