Magento 2 is a fairly significant step forwards from Magento 1. After 2.0 is released, it has been publicly shared there will be a more frequent release cadence. This has pros and cons, some of which are explored below. But also interestingly should there be a more detailed strategy before GA to help extension developers with Merchants who want to move to Magento 2.0 before it is released? Oh, and I know there is interest in this area because of the rather long and active twitter thread. Let’s see if that turns into comments on this blog post or not. (Hint hint!)

Disclaimer: This post contains my own thoughts and not necessarily that of my employer.

Magento 2.0 – Lightning Strike

A lightning strike or big bang release is where a significant amount of functionality is held back until a release has enough “bang” to make an impression. Magento 2.0 falls into this category. (All the code is being pushed weekly, but GA is being held back from the normal Magento 1.X release cadence.)

A benefit of a big bang release is multiple disruptive changes can be made at the same time. Disruptive changes are more expensive for Merchants to migrate between releases, so reducing the number of them does help reduce costs for Merchants. The rest of the time changes are kept to a minimum for backwards compatibility reasons.

There are a number of potential disadvantages of a big bang release:

• The world is changing around you. If you take too long to release you will be out of date before you do release.
• The larger a project, the harder it is to manage and keep on top of, meaning the greater the chance for project failure.
• With open source, there is a risk that some users will take and go live with intermediate versions of the code. This can reflect poorly on the product if problems arise. It can also make support more confusing for extension developers as customers may not care that they took a beta of the code and went live with that unsupported version of the code.

Magento 2.1+ – Rolling Thunder

Post the Magento 2.0 release, it is planned to increase the frequency of releases. Get one area of functionality completed then ship the code. Quarterly was one suggested increased frequency, which would roughly line up with internal Scaled Agile timelines.

A benefit of rolling releases is new functionality can hit the market sooner, instead of having to wait for all the other functionality in the release.

Negatives (or at least challenges) include:

• Need to keep an eye on quality. To help here, need to reduce the test cycle time. This is one of the reasons behind the investment of test automation in Magento 2.
• Merchants don’t really want to pay for upgrades in time or money. They should be reliable and effortless with low risk.

So how to overcome these challenges?

Versioning Strategies

Service Contracts are a personal plan to help keep the impact of change lower on extension developers and Merchants. By having the contract more stable, the impact of new releases is minimized.

An extreme may be to version service contracts separately to the rest of the module. This would allow a service contract to remain unchanged across multiple releases. This may mean an extension developer could avoid having to retest their extension per release.  (Actually, I would always retest – but the retest is more likely to work first time. Code changes would be less likely.)

Versioning is also important at the global level. My personal favorite versioning scheme is to create a release branch (e.g. for Magento 2.0) *before* the final release. It is common that some teams will finish their contribution for a release before others. So let them move on to the next release immediately by creating the release branch early. Then create tags on the release branch for release candidates, and finally do the release from the branch. (Any changes made on the branch should be back-ported to mainline.)

The release candidates are important, especially for a project like Magento. They offer a signal to extension developers to start retesting their extensions before the final release comes. (This is true for all releases, not just 2.0.) They may need to do a final test after the official release drops, but they can inspect the change history and make appropriate decisions. Having the release candidate made from a branch also means the code can actually sit there unreleased for a period of time to give extension developers a time window of stability.

Talking of extension developers, a benefit I did not mention above of regular (or at least predictable) releases is it makes planning easier for extension developers. Knowing what is coming and when in advance assists with resource planning.

Magento 2

So what about during Magento 2 development when releases are not occurring? How to control the release cycle? Is it appropriate to try and stop Merchants going live with Magento 2 before GA? One tweet indicated a potential challenge for extension developers was Merchants who insist building a site on the next technology (in this case 2.0) even if it has not reached GA yet. That then puts pressure on extension developers who at the end of the day want to provide great service to their customers. But how are they to support multiple customers on different levels of beta releases?

Some ideas included to control adoption of Magento 2 include

• Don’t release on Composer until release candidates are available.
• Don’t make any Magento 2 extensions available on Connect, to slow down the perception of Merchants that Magento 2 is ready for production.
• Remove some critical functionality from GitHub until the product is closer to GA.

The other approach is to accept that it may happen and define stable release candidates earlier to at least reduce the number of versions extension developers need to support. (My personal advice for a customer planning to go live with a site is to stick with 1.X for now. It is going to be supported for many years to come.) However community ideas here are welcome, even encouraged, to be left in the comments field below. Magento has its own plans, but feedback always appreciated and strategies here could have a big impact on extension developers. Feel free to have your say.

Other Challenges of More Frequent Releases

Obviously details like Magento EE customer support contracts need to be sorted out – support contracts may currently say things like “the last 2 releases”. Obviously this needs to be addressed if releases start being released more frequently. This is not my area so I won’t speculate here – I will however say Magento knows it needs to address this.

Another question is whether each release increments the version number. Do we release 2.1 a quarter after 2.0, or do we release new modules under the same 2.0 version number if existing code has not changed? (If only new functionality has been added, maybe the rest of the code can remain unchanged.) This to me is a really interesting question. The goal is to make new functionality available faster, not simply increment the version number for the sake of it.

Another interesting question to me is how to release more frequently (which also implies allowing sites to upgrade with less effort) without creating unnecessary overheads for extension developers to retest their extensions each time.

Conclusions

I am reminded of what I heard Jim Collins (author of books such as “Good to Great” and “Bulit to Last”) once say – you should normally change around 20% of your product each year so it continues to evolve without too much disruption to your customer base. Magento 2.0 is an exception to this rule, with the intent to then stabilize the platform for future releases after that.

If you are an extension developer, what are your thoughts on the above? I wrote this blog primarily because a long twitter thread started just before Black Friday. Right before peak is not the right time to be distracted, so I decided to create this blog post and schedule after the weekend including Cyber Monday. If you have ideas on the best strategy here for Magento 2.0 and beyond releases, please leave a comment below. Thanks!