feat: add upstream version to metapackage composer.json for runtime use

[rhoerr]

This is the build-release portion of changes for mage-os/mageos-magento2#108

Some extensions use version comparison in Magento to determine what code to run. This is a problem for Mage-OS, where we replace Magento's getVersion() number (IE 2.4.7) with the Mage-OS version (IE 1.0.5), causing old incompatible code to run.

The idea here is:

• Magento gets the version from composer.lock for magento/product-community-edition, via https://github.com/rhoerr/mageos-magento2/blob/7bed30c9ea2b6e31130d4cead3e191871fb9b98e/lib/internal/Magento/Framework/App/ProductMetadata.php#L118
• Mage-OS replaces that version number during our existing build/release process.
• To fix it, we change getVersion to return the equivalent Magento version, and add a separate method to get the Mage-OS version.
• To do that, we have to know what the equivalent upstream Magento version is for a given release.
• To do that, we can store the upstream equivalent version from the build params into the composer metadata for the mage-os/product-community-edition metapackage.
• Composer lets us store arbitrary data in composerConfig.extra.
• We get the upstream version from the replaceVersionMap (package versions for the defined upstream release) for magento/product-community-edition, which contains the expected version number, EG 2.4.7-p3.
• We store that on composerConfig.extra.magento_version, so that Magento can load that from the lock file at runtime, the same way it gets the metapackage version now.

[rhoerr]

I have opened this as a draft PR, because I believe it will work as intended, but I have not been able to test and confirm that it actually does.

I currently get an error on mageos-release, unrelated to these changes:

$ node src/make/mageos-release.js --mageosRelease=1.0.5-p5 --upstreamRelease=2.4.7-p3 --skipHistory
...
5/7 Packaging [1.0.5-p5] Magento_nl_NL
6/7 Packaging [1.0.5-p5] Magento_pt_BR
7/7 Packaging [1.0.5-p5] Magento_zh_Hans_CN
Packaging Magento Base Package
Determining dependencies...
Removing existing temporary workdir at /tmp/workdir-f9f29ed3731da9dea37dc7fc7dab22fc
Preparing temporary copy in /tmp/workdir-f9f29ed3731da9dea37dc7fc7dab22fc
Running composer install --no-progress --no-plugins --no-scripts
Inspecting 6125 files to determine composer dependencies...
node:events:497
      throw er; // Unhandled 'error' event
      ^

Error: spawn php-classes.phar ENOENT
    at ChildProcess._handle.onexit (node:internal/child_process:286:19)
    at onErrorNT (node:internal/child_process:484:16)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
Emitted 'error' event on ChildProcess instance at:
    at ChildProcess._handle.onexit (node:internal/child_process:292:12)
    at onErrorNT (node:internal/child_process:484:16)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn php-classes.phar',
  path: 'php-classes.phar',
  spawnargs: []
}

Node.js v20.15.1

I've tried various things including updating composer, reinstalling node packages, and updating node packages, but to no avail.

This error appears to be the same affecting the upstream mirror builds: https://github.com/mage-os/generate-mirror-repo-js/actions/runs/12732736267/job/35488270194#step:8:331

Which makes me wonder if the entire build process is currently broken.

[rhoerr]

I opened a separate issue for the build error. #190

[rhoerr]

Tested, made some fixes, works as intended now. With the new code, the metapackage includes the upstream version as extra.magento_version, which will be accessible to Mage-OS at runtime:

{
  "name": "mage-os/product-community-edition",
  "description": "eCommerce Platform for Growth (Community Edition)",
  "type": "metapackage",
  "license": [
    "OSL-3.0",
    "AFL-3.0"
  ],
  "require": { ... },
  "prefer-stable": true,
  "version": "1.0.5-p24",
  "extra": {
    "magento_version": "2.4.7-p3"
  }
}

[fballiano]

Nice! should we merge and rebuild 1.0.5? or should we release a new one?

[rhoerr]

It'll have to be part of the next release, because the addition will change checksums.

[Vinai]

👍🏻

[fballiano]

@rhoerr is it safe to merge it now or do we have to wait for some other task?

[rhoerr]

I believe it's safe to merge. It won't affect past releases because those are already built and tagged.