Drop support for end-of-life versions of Composer

$ composer --version
Composer version 2.5.2 2023-02-04 14:33:22
$ php -v
PHP 8.1.13 (cli) (built: Dec  7 2022 23:32:13) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.13, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.13, Copyright (c), by Zend Technologies

and

..........                                                        10 / 10 (100%)

Time: 00:20.813, Memory: 10.00 MB

OK (10 tests, 48 assertions)

⇒ 2.5.2 is fine.

Other reason to support this is https://endoflife.date/composer

→ Can you please find the official source and link that instead?

Looking forward to reading your proposed resolution! 🤓 And that should help you specify a better title too 😊

I am sure we need to do this for the reason stated.

Change composer constraint to supported version for tests to pass.

We should support , supported versions of the composer but I don't think that is the only reason those tests are failing.

It looks like we were adding an invalid package. Maybe 1 composer version is more strict on the checks

I think 📌 Run `composer validate` after FixtureManipulator commits its changes Fixed will help with this because I have found it turns up errors like this that we were missing.

Also yash when you create an issue unless it is something we definitely should not work on now please add the sprint tag as I am am almost always filtering by this, thanks

the current fix in the MR probably belongs in 📌 Run `composer validate` after FixtureManipulator commits its changes Fixed

Hi @wim.leers I am unable to find the official documentation for https://endoflife.date/composer. Removed test fix as it is going to be fixed in 📌 Run `composer validate` after FixtureManipulator commits its changes Fixed . @tedbow wants to discuss with you, if we want to remove support for composer 2.2 version.

Wow, that is indeed surprisingly hard to find!

Best sources I could find:
- https://blog.packagist.com/composer-2-2/
- https://github.com/endoflife-date/endoflife.date/commit/c8ee80ba5c7fbf33...

But … yeah … perhaps https://endoflife.date/composer is then the only choice to link to 😞

It makes sense that we want to discuss dropping 2.2 support, but dropping 2.3 support in favor of a newer version @tedbow is fine with. So marking for that.

Also, why are you proposing to require only 2.4.4 if that is already unsupported today? 🤔 Why not require 2.5?

I was thinking that the test will pass for all the versions above 2.4.4 but I am more lean towards setting the version to 2.5 and above, so made those changes in the MR (Ignored 2.2 version for the discussion).

👍

This is now blocked on the discussion @tedbow and you mentioned!

But in the meantime, could you already update the title to reflect the current direction? 🙏😊

👍 Thanks!

Wim Leers → credited phenaproxima → .

📌 Add a validate() method to ComposerInspector to ensure that Composer is usable Fixed moved the constraint to a different place. This MR needs to be updated.

@yash.rode We did discuss this on Friday. In the future, please update the issue accordingly if I didn't.

The conclusion was: support everything listed in https://endoflife.date/composer — that means the LTS (2.2) and the current version (2.5).

The test is passing on my local but failing on drupal CI.

Re-titling for clarity.

👍 to what @phenaproxima said.

Let's also add an @see pointing to composer's security advisory.

Is the purpose of this issue solely to drop support for potentially insecure Composer versions, or was there something that Composer fixed in 2.2.12 and 2.5, but not in 2.3 or 2.4, and we rely on that fix? If the latter, what was that fix?

We already don't support Composer 2.2.11 or earlier, because of the security fix made in 2.2.12.

We currently support 2.3.5 and up, but 2.3 and 2.4 are EOL. So this is really just about dropping support for EOLed versions of Composer. Re-titling for clarity.

This still did not yet address what I asked in #21:

Let's also add an @see pointing to composer's security advisory.

Given this is an alpha blocker, fixed that myself and slightly tightened test coverage for maximum confidence: now all boundaries are tested 👍

Glad to see this done! 🚀

Automatically closed - issue fixed for 2 weeks with no activity.