Magento currently maintains and accepts pull requests to 3 separate branches on GitHub.
2.1-develop- Code targeting this branch will go into a 2.1.X release
2.2-develop- Code targeting this branch will go into a 2.2.X release
2.3-develop- Code targeting this branch will go into a 2.3.X release
While the notion of allowing the community to contribute to each release line sounds good on paper, in practice it doesn’t work out so well in my experience.
In this post I’ll outline the issues with this process as I see them.
NOTE: This post is not intended as an attack on the community engineering team or any of the maintainers who are doing a great job fielding managing community contributions. Instead, this is overall criticism of Magento's approach on a whole to managing it's release lines.
As far as I can tell, the most “correct” way to contribute a fix or enhancement to Magento core is by porting it to each applicable branch. My colleague Todd Christensen is a model citizen in doing so as can be seen in these three pull requests…
This would seem to be the “correct” way of contributing as it ensures the code will make it into each applicable Magento release lines.
There are a few problems with this strategy…
In order to follow this process, as a contributor this means…
This sums up to a very significant increase in the amount of time it takes to contribute to Magento.
Personally, as a contributor, I’d rather not have to put in all this additional extra effort if I don’t even know if my change is something that will be accepted by Magento.
I’m making an assumption here that PR-ing your changes to each of the release lines is the most “correct” way to contribute, however nowhere is that process officially documented. Magento’s contribution documentation simply states that PRs can be issued to any of those branches. As such, only savvy contributors are likely to be aware of this process.
As you’d assume, since this strategy isn’t documented neither is it enforced. This can cause a multitude of issues. Case in point, in pull request #12935 I added an enhancement to the
Magento_NewRelicReporting module in
2.2-develop. It was merged, with no evident plan for getting the same changes into
2.3-develop (in other words a newer version of Magento was lacking a feature that was already available in an older version).
As a good samaritan I took it upon myself to forwardport the changes to
2.3-develop at which point I saw that one of the community maintainers, Ihor Sviziev, had already taken it upon himself to do the same. However, despite contributing literally the exact code as me, which had already been merged to
2.2-develop, his pull request received extensive scrutiny during code review with many requests for changes. As such, the implementation specifics will diverge across release lines, making it more challenging to automatically and easily port changes to the
Magento_NewRelicReporting module across branches.
Stability and consistency across its release lines should be Magento’s problem to solve, not the community’s. It is in fact in their best interests to have a product that is stable and consistent across versions. Imagine the following scenario…
As you could imagine, the client probably has a pretty bad taste for Magento at this point.
As such I think the most sane thing for Magento to do is to have contributors contribute to a single development branch. Release managers at Magento should then be responsible for porting fixes and features into release lines.
Hi, I'm Max!
If you'd like to get in touch with me the best way is on Twitter.