Managing multiple meta-packages

The original idea of removing Magento 2 packages by using the composer replace syntax is not something I came up with: I'm standing on the shoulders of giants like integer-net. But where they paved the way with their research, I tried to turn this into reusable composer packages that are more easily installed.

Currently, this involves 6 different repositories:

• yireo/magento2-replace-bundled removes third party bundled extensions
• yireo/magento2-replace-core removes optional core modules
• yireo/magento2-replace-graphql removes optional GraphQL modules
• yireo/magento2-replace-inventory removes optional MSI modules
• yireo/magento2-replace-content-staging removes optional Content Staging modules
• yireo/magento2-replace-all removes all packages listed in the other packages, which sometimes fails :o

Each repository contains branches for Magento 2.3.1 and up to the current version (2.3.5, but 2.3.6 and 2.4.0 coming up next). And because maintaining all of these packages and branches and releases is quite a burden, I've written my own little scripts to automate releases: yireo/magento2-replace-tools

The flaws of the previous release management

When I started with offering these packages, I came up with a pretty simple release mechanism. Each repository (so each replacement meta-package) has a branch per Magento version. For instance, Magento 2.3.3 corresponds with branch magento-2.3.3. And as soon as that branch was finalized, a release 2.3.3 was brought out.

Unfortunately, nothing is perfect. Soon after releasing 2.3.3 (and this applies to all other versions as well), issues were found, debated and fixed. And new releases were required. Obviously, incrementing 2.3.3 to 2.3.4 was not supposed to happen, so I applied a versioning that is not entirely semantic, but seemed acceptable: 2.3.3.1. Unfortunately, as soon as this saw daylight, it appeared that composer had big issues with this.

So I turned to another versioning strategy: 2.3.3-p1 (just like Magento did). Unfortunately, this did not work nicely with upgrades either - especially, because the default matching pattern applied by composer (^X.Y) did not include these patches. So finally, I've decided to start fresh and come up with an entirely new strategy.

The new and current release management

Instead, I'm going to stick with semantic versioning (X.Y.Z). And because that's only allowing for three digits and I would need four, I'm simply dropping the first digit. In other words, all versions 3.3.* support Magento 2.3.3, all versions 3.5.* support Magento 2.3.5, etcetera.

Unfortunately, this is a major upgrade compared to the original versioning strategy I used (bumping from 2.3.3-p1 to 3.3.0). And still, it is important to upgrade if you don't want to break your site because of undocumented dependencies, bad DI compiles, etcetera.

I found this so important that I decided to upset the rest of the world by removing the previous releases as well. I've done this before as one of my earliest strategies and people got angry at me. And I guess this is definitely going to hurt as well - especially if there is a CI development. But I feel this is needed to move on with a better versioning strategy that allows for endless fixes without major version changes, except for when moving from 2.3 to 2.4.

To upgrade to the new major, you will need a command similar to the following (the example is for 2.3.5):

composer require yireo/magento2-replace-core:^3.5

What about 2.3.6 and 2.4.0?

My intention is to support 2.3.6 and 2.4.0 as soon as they come out. The branches are prepared (based on 2.3.5) and ready for release. Unfortunately, there is little sight on which packages will be included with 2.4 because the composer progress is excluded from GitHub.

To upgrade to 2.4 a command like the following is needed:

composer require yireo/magento2-replace-core:^4.0

What about sample data?

I hit performance issues with integration tests lately, solely because the sample data were installed. In other words, sample data don't belong in CI environments and they don't belong in production environments either. I am going to work on a simple replacement package that removes sample data modules as well. The repo will be yireo/magento2-replace-sample-data

CI runs via GitHub Actions

To make sure replacements are working with specific Magento versions, I have setup GitHub Actions that basically do an install the right way: First setting up the composer project, before downloading anything. Then adding the replacement package. Then installing everything. Last but not least, DI compile is run to hopefully narrow down possible issues. Thanks to these CI jobs, I've become more confident that the replacements mostly work. Note the word mostly, I'm completely selious about that.

Last notes: A disclaimer

Please note that this is not a dummy solution. There is no easy way of removing modules that ship with the Magento core and by using this solution, I'm assuming you know your way around composer. There is quite a troubleshooting section in the yireo/magento2-replace-tools repo, which - for the major part - mentions various ways of adding composer packages. If the CI jobs have ran successfully and the same replacements