-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split Magento and Mage-OS versions in ProductMetadata for compatibility #115
base: release/1.x
Are you sure you want to change the base?
Conversation
lib/internal/Magento/Framework/App/DistributionMetadataInterface.php
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the fact that the original getVersion()
goes back to return the magento version. I see that there's a getDistributionVersion()
, is there also a getDistributionName()
?
Code changes, for further consideration. I was able to create a test build with the composer data, so I can try the actual UX aspect now (maybe later this week). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this a lot
I fixed unit test errors, those pass now. Integration tests keep failing for unrelated process errors. I'm not sure if there are any issues caused by these changes. |
Description (*)
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), which makes some extensions think it's an old version of Magento and run old incompatible code.
The idea here is:
extra.magento_version
on the product metapackage composer JSON, which is stored in composer.lock and already read by Magento.getVersion()
(viagetSystemPackageVersion()
) is changed to read that upstream version (like 2.4.7-p3), for intercompatibility with Magento. That will return the equivalent version for releases going forward. Side benefit: it'll be easier to know what the equivalent version being run actually is.getDistributionVersion()
(viagetSystemDistroVersion()
) will return the distribution version (like 1.0.5), from the metapackage version. If any code needs to know the exact Mage-OS version, it can use this to get it.getDistributionVersion()
instead ofgetVersion()
.Related Pull Requests
Fixed Issues (if relevant)
Manual testing scenarios (*)
bin/magento --version
; see output like:Mage-OS CLI 1.0.5 (based on Magento 2.4.7-p3)
Mage-OS ver. 1.0.5
Questions or comments
Opening this as a draft PR due to inability to test it end to end, as the build process is currently broken.
Unit/integration tests might be affected and require further attention. I didn't get there yet.
I split
getVersion()
, but notgetName()
, which returnsMage-OS
rather thanMagento
. Should that be split too?I created a new interface
DistributionMetadataInterface
, on the thinking that third parties could use that (instanceof DistributionMetadataInterface
) to help determine whether an install is Mage-OS, and that this would be better for backwards compatibility by not introducing new methods toProductMetadataInterface
. Thoughts?Contribution checklist (*)