Magento 2 Roadmap Through to GA

hurdlesWondering what is coming for Magento 2 through to GA? Here is a high level (unofficial) summary.

Disclaimer: This blog does not constitute official communication and does not necessarily reflect that of my employer. And even if this was official, the plan would be subject to change without notice. We are using Agile after all! But I just happen to have this slide up on my screen that I think has been shown in public somewhere before…


Internally Magento is using development practices similar to the Scale Agile Framework. This is an approach to get multiple Agile teams working together on long term projects. Sprints are grouped into larger deliverables called Potentially Shippable Increments (PSIs) – we call them milestones because we ship code every week to the public GitHub.

Currently our milestones don’t always align with quarters, but it’s easier to talk that way. So while I say quarters in this post, there are really internal dates for each milestone and those dates are what we really target. (So please, don’t say “hey, the quarter just ended – the project is slipping!” We are taking the date commitments seriously.)

Key dates:

  • End of 2014 – Developer Beta
  • End of Q1 2015 – Developer RC
  • Q3 2015 – Merchant Beta
  • Q4 2015 – General Availability (GA)!


First, there are two areas of work that are likely to continue right up until GA.

  • Service Contracts: We are going to continue to introduce service contracts on top of as many modules as we can as a part of improving the “official” API of a module. We are also going to refactor as much of our own code as we can to use the new APIs (which is by far the bigger job) and thus enable replacement on the module implementation.
  • Performance and Scalability: We are going to continue working on improving performance and scalability right up to GA. This is a cycle of measure, analyze, improve, and measure again. There are some new features that may get identified along the way as well, but we want to also tune the code we have as much as we are able before release. (There are different areas of work here: PHP server time, page load speed, horizontal scalability, etc.)

Developer Beta (Q4 2014)

By end of 2014 the proposed major platform changes will all in place. This includes upgrading the tech stack (newer versions of PHP, Apache, MySQL and so forth). It also includes more modern coding style, new theme inheritance infrastructure, Composer support, introduction of service contracts, better refactoring of HTML, CSS, and JS assets, and lots more besides. We are wrapping up this work now.  (Yay! A Christmas present!)

Developer RC (Q1 2015)

The Developer Beta period starts end of Q4 and runs through Q1 2015. The goal is to collect feedback on platform changes made to date, make any adjustments (hopefully not too many), address quality issues (get bug counts down), etc. The goal by “Dev RC” is to have the platform stable enough for developers to start porting their extensions with a low risk of impact before GA. If you want to have more influence and get Magento 2.0 to change how things work, you should start early. If you want things that bit more stable, wait until the end of this period. The goal is to complete any remaining platform changes during Q1, so reporting things at the end of Q1 is cutting it a bit fine!

Merchant Development (Q2 2015)

Q2 focus will shift from primarily platform focus to more Merchant functionality focus. Checkout is going to get some much needed love and care. Some Merchant Admin flows are going to get some attention too. Less interesting to the CE community, this is also when EE modules will get more attention (we wanted to get the platform out first to give extension developers more time to port their code as well, so deferred what EE work we could).

Merchant Beta (Q3 2015)

There will be a beta period for Merchant functionality around Q3, much like there was a beta period for the platform. Merchant development will continue in the background, getting ready for final release. This may be one of the more painful stages of the project. When to stop making any changes to give extension developers that stable time so they can make any final adjustments? While we are not doing wholesale platform changes at this time, we will probably still be making changes. Any change has the potential to impact extensions. We want to minimize this impact, but we cannot change the code and guarantee zero impact at the same time.

Merchant GA (Q4 2015)

The final release will be sometime during Q4, subject to final tweaking based on Merchant Beta feedback. I will however say there is no appetite for it to slip into 2016 – it will be more what features to defer if the date looks at risk.  (Of course our planning 1 year into the future is perfect, so there is zero risk here! Right?)

When Should I Port My Extension?

Here is my personal guidance:

  • Port early if you want to provide feedback and potentially get the platform changed to meet your needs. Dev Beta is the recommend time for this. That is, end of this year.
  • Dev RC is when the platform should be pretty stable. That is, end of Q1 next year.
  • Port later if you want maximum stability of platform under you.
  • Wait until GA to start porting if you want absolute stability. You may be behind your competitors getting to market on 2.0 (so I do not recommend this), but if you want a super stable platform with zero risk of rework then GA is for you.

Be aware that we are going to continue pushing weekly releases to the public GitHub. It won’t stop until GA. So the above dates are more lines in the sand than representing major dates where a huge code drop is going to occur.

We know extension developers are not going to be happy if the platform is not stable so we are trying to front load work with the biggest impact. But on the other hand, making changes before Magento 2.0 GA is the best chance to get things right for many years into the future, so it seems prudent not to promise absolute stability before GA.


This post does not attempt to list all work being done. It is only meant to be a high level thematic roadmap showing where the major focus of effort is likely to be directed. Plans may change, but hopefully this is useful to you who are starting to think about when to perform activities such as porting your extensions to this wonderful new platform. (Hint! Hint!)


  1. Hi Alan. I’d just like a quick clarification before I clone Magento2’s git ( to help in Q2-Q3 Merchant Dev/Beta stages. Is it for both EE and CE versions? The M2 CE git ( is rarely updated and has relatively few commits. Has Ebay/Magento abandoned that git altogether? Thanks.

    1. magento/magento2 is the main code base. It contains all CE code. EE is in a private repo – not public. It has the extra EE modules (CE modules are shared).

    2. Oh, and the CE repo I think is the CE meta package for composer. It is separate as it will be versions with CE product release numbers (unlike main repo which will use semantic versioning rules).

      1. That all makes sense. Thanks for that and for all your work. Everything I’ve read so far seems promising. I look forward to seeing the current state of M2 and doing what I can to help.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: