You may have seen our recent Release Announcement of SDL Tridion Sites 9.0 in Q4 of 2018 as part of the SDL Tridion DX suite which offers exciting new features and architecture!

DXA 2.1 was also released shortly after and it showcases the new features and leverages the new architecture of SDL Tridion Sites / DX. 

The following notes in the DXA 2.1 release announcement created some ambiguity which required some clarification:

• DXA 2.1 works with SDL Tridion Sites 9 only. We are working on an SDL Web 8.5 compatibility pack, which will be available as part of the DXA 2.2 release. 
• The DXA 2.1 release is for .NET Web Applications only. Feature parity for Java Web Applications will be achieved in scope of the DXA 2.2 release.

Furthermore, right after the release of SDL Tridion Sites 9.0, there were some rumors that DXA 2.0 does not work on SDL Tridion Sites 9.0.

This gave a few people an impression that they urgently need a DXA 2.2 release, but do they really?

Let me try to clear the situation by answering the following questions:

• Does DXA 2.0 work on SDL Tridion Sites 9.0?
• Why does DXA 2.1 not work on SDL Web 8?
• Why was DXA 2.1 only released for .NET Web Apps?
• What will DXA 2.2 offer?
• So, what will be the added value of the DXA 2.2 release?
• How does DXA 2.2 relate to Tridion Sites 9.1?

Does DXA 2.0 work on SDL Tridion Sites 9.0?

Yes, it does; this relies on backwards compatibility of SDL Tridion Sites 9.0 / DXD 11.0.

There is a known backward compatibility issue with DXD 11.0 Context Service, which is not compatible with CIL.NET 10.1 (used by DXA.NET 2.0), we do have a CIL.NET hotfix available for this.

There were also some reports about compatibility issues with the DXA Resolver UI Extension, but it turned out that these only occurred in certain deployment scenarios; see this Q&A on Tridion Stack Exchange.

Why does DXA 2.1 not work on SDL Web 8?

As mentioned, the main goal for DXA 2.1 was to showcase and leverage SDL Tridion Sites 9.0 features and architecture. In particular: it showcases use of native Page Regions in Content Manager (CM) in the DXA Core Module and Example Site and Content Mashups in the new SDL Tridion Docs Mashups Module.

For this purpose, (some of) the DXA 2.1 CMS packages contain new concepts like Page and Region Schemas and Pages with native Regions. These packages can obviously not be imported in the Content Manager of SDL Web 8.

On the Delivery side, DXA 2.1 by default leverages the new GraphQL Content Service, but it is possible to configure it to use the OData Content Service and (now “legacy”) DXA Model Service.

So: DXA 2.1 does work on CD 8.1.1 and higher (if properly configured) but requires SDL Tridion Sites 9.0 on the CM-side.

Why was DXA 2.1 only released for .NET Web Apps?

We wanted to release DXA 2.1 shortly after SDL Tridion Sites 9.0.

At some point it became clear that we would have to release quite a bit later in order to release both .NET and Java (like we usually do with DXA).  It was decided to release DXA 2.1 for .NET first, in order to have a  SDL Tridion Sites 9.0 showcase as soon as possible and do a Java release later.  We ended up with a plan to skip a DXA 2.1 Java release altogether; see below.

What will DXA 2.2 offer?

The scope for DXA 2.2 release is currently defined as follows:

• Feature parity for Java
  • Support for native Page Regions
  • Support for Content Mashups
  • Leverage GraphQL Content Service
• Re-introduce Platform support for SDL Web 8
  • In particular: support importing DXA 2.0 style CM packages. Obviously, DXA 2.2 will not showcase native Page Regions nor Content Mashups when installed on an SDL Web 8 system.
• Incorporate Community Pull Requests
  • Although we are trying to make the DXA Framework as flexible as possible, there will be cases where customizations to the framework are required. We expect our Community to perform those customizations and contribute them back in the form of Pull Requests.
  • In order to keep the DXA Framework upgrade impact minimal, we want to prevent that customization have to be re-applied after an upgrade. So, we want to incorporate Community Pull Requests in the upcoming release.
  • Obviously, it’s not only about minimizing upgrade impact; others can now also benefit from the fixes and enhancements made.
  • I hope this illustrates why contributing back in the form of Pull Requests is important, both for SDL and the Community.
• Known Defect fixes
  • Besides fixes contributed by the Community, SDL itself also fixes the most severe issues it is aware of.

Note that the last three bullet points are related: we want to create a DXA release which incorporates Community Pull Requests and contains fixes for severe defects in general, but we don’t expect all customers to be on SDL Tridion Sites 9.0 yet, so this makes it important to support SDL Web 8 too.

So, what will be the added value of the DXA 2.2 release?

Well, that depends where you’re coming from, of course. 

Because of the extended platform support in DXA 2.2, there are quite a few supported upgrade paths, including DXA 1.x, DXA 2.0, SDL Web 8 and SDL Tridion Sites 9.0.

I created a few from/to tables.  For simplicity I’m omitting DXA 1.x upgrades here.

 As you can see, two bullet points apply to all upgrade paths:

• Incorporate Community PRs
• Known Defect fixes

Some upgrade paths give you additionally:

• Leverage SDL Tridion Sites 9 features/architecture

How does DXA 2.2 relate to SDL Tridion Sites 9.1?

Well, as you can see above, it doesn’t. :-)

That is: the plan is to release DXA 2.2 before SDL Tridion Sites 9.1 is released.  So, showcasing/leveraging SDL Tridion Sites 9.1 features/architecture will come in a subsequent DXA release.

The bottom line

Wow, this has become quite a read!

I hope that people take the time to study it and that it clarifies the situation.  In particular:  do you really need DXA 2.2 and why?

Of course, the DXA 2.2 release will provide significant added value; we’re not doing a release for the fun of it. :-)

But it is important to realize what the added value is in your case and what the alternative may be.