fix: remove versions dependent on EOL composer 1

[rhoerr]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/mage-os/github-actions/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

Installation and integration tests fail for 2.3.7 to 2.4.1 because they require Composer 1, which no longer works. Packagist ended Composer 1 support as of September 01 2025.

Fixes: https://github.com/mage-os/generate-mirror-repo-js/actions/runs/18158077121

What is the new behavior?

No longer attempts to build versions below Magento 2.4.2.

Does this PR introduce a breaking change?

• Yes
• No

Will no longer support Magento versions below 2.4.2 (but they're already inherently broken).

Other information

[rhoerr]

@damienwebdev Is this an appropriate change, given the circumstances?

Installation and integration tests fail for 2.3.7 to 2.4.1 because they require Composer 1, which no longer works. Packagist ended Composer 1 support as of September 01 2025.

Fixes: https://github.com/mage-os/generate-mirror-repo-js/actions/runs/18158077121

[fballiano]

I proposed to remove the old beta releases before, so I completely agree on this PR.

[rhoerr]

Latest mirror build has integrity checks mostly fixed, except for these affecting 2.3.7-2.4.1, and preexisting constraint edge cases for a couple releases in 2.4.4 and 2.4.5. https://github.com/mage-os/generate-mirror-repo-js/actions/runs/18217417183

[damienwebdev]

I kinda feel like we need a different kind for this use-case. Perhaps useable.

Most people (from my original repo and what I use internally) use currently-supported (the default)

all (what the generate-mirror-repo-js uses) is a special use-case for people who need to enumerate the whole list of all magento releases. When @danslo wrote that workflow, that made sense. However, given that software is not stagnant, what he may instead of have meant to say was all-useable or useable or all-modern.

Instead of modifying the raw data, what we should instead do is modify get-matrix-for-kind to handle this new kind (Also adding docs as necessary)

The only complexity I can think of is how "useable" is determined. I'd probably add a flag to the raw json data on each version indicating whether its currently useable or not. We could instead do it based upon some unique computation of "is it composer 1", "is it RabbitMQ 1+", etc, but that sounds painful and esoteric. I'd rather just decide based upon world events (the deprecation of composer 1 for example) when something becomes unusable.

[rhoerr]

Thanks Damien. I'll see what that means in terms of real world changes here.

I like the useable kind of flag idea. Simple enough concept.

I think this isn't a blocker for the next release round in ~10 days, so we can take some time to get it right. We can and have chosen to ignore certain integrity test errors at times for expedience. This doesn't break processes, just throws unavoidable warnings right now.