Update on the DD4T and DXA merge

During the 2016 Tridion Developer Summit in Amsterdam we announced the DD4T and DXA merge, and there have been several blogs written about it, some of them I have listed in one of mine. By now it is due time for an update, because it has been too quiet around this topic, while a lot has been happening under the radar actually.

Let me start with listing what exactly has been happening since the announcement in May 2016. Since that time, we have mostly been keeping ourselves busy with plans around the merge, and at the same time we were also still working on DXA 1.x releases. As shown in the next picture, we have released DXA 1.5, 1.6 and 1.7 since then, which would total the amount of releases in 2016 to five (six if you include DXA in the Microsoft Azure marketplace as announced at TDS).

Details on each of those releases can be found in the press releases and the documentation:

During the 2016 SDL Web MVP Retreat it was decided that the name of the merged product would become DXA 2.0 and we discussed details of the merge. Before that a Steering Group was already formed and a manifesto for the merge published (more information around the merge can also be found on the Confluence space donated by Trivident). After that unfortunately it became a bit quiet around this topic, don't get me wrong, a lot has happened, but we failed to communicate and involve the community. I planned to fix that with my presentation at the SDL Web Dev Summit in India and this blog post as a first follow up.

Merging

Simply put, the way I see it there are basically two ways to perform this merge. We can:

  1. Just "change namespaces" and call everything DXA

    The pros of that will be, relatively easy backwards compatibility and upgrade scenarios. The cons however are, no innovation for the duration of the merge (we are looking at almost a year), and the risk that we’ll create a "hydra" (multi headed monster).

    or:

  2. Start working on our future vision

    The pros of that obviously are innovation, and we can truly keep the best of both worlds. The 
    cons unfortunately will be, we will have to introduce breaking changes.

Now in reality there are of course many hybrid scenarios possible of these two, but the risk of them becoming quite similar to option #1 is high. Furthermore the pros and cons as I listed theme here are quite bluntly put, they are meant to illustrate the point, because in reality it isn't so simple or black and white as I stated it.

We (the steering group and the SDL DXA development team) decided to go for option #2 and plan to mitigate the risks of breaking changes by interoperability scenarios, upgrade support (possibly supported with scripts), and migration guides (most likely documented manual steps).

I will follow up with a few more blog posts around the planning and architecture of DXA 2.0 soon. Stay tuned!