While writing this the finishing touches are being applied to DXA 1.6, which will be a sort of a special release. In DXA 1.6 we will be deprecating SDL Tridion 2013 SP1, which basically means it is the last release to support the 2013 SP1 version of SDL Tridion. There are a few compelling reasons why we plan to drop support for 2013 SP1, the biggest one being that we need room to focus on the SDL Web releases.

Since the release of DXA 1.2 in November 2016, we have been releasing a new version roughly every quarter, and added support for SDL Web 8 CU1 and SDL Web Cloud, including the different CIL versions which have been introduced for SDL Web Cloud. If you look at an extract of the acceptance test report for DXA 1.6, you see that most of the test cases are executed 6 times, due to the different versions supported, and DXA being available in both .NET and Java. 

Towards the end of 2016, we will see SDL Web 8.5 being released, which is an important release that we should not ignore. Onno Ceelen has mentioned some details of it already last month in his blog post. Right after SDL Web 8.5 is released, we are planning the release of DXA 1.7, which will be fully tested and compatible with this new release of SDL Web, so to make room for this we have decided to drop support for 2013 SP1.

Dropping support for SDL Tridion 2013 SP1

So what does this exactly mean, dropping support? It means we will no longer test on 2013 SP1, and also remove the specific code in DXA that makes compilation against 2013 SP1 available (when SDL Web 8 was released, that introduced some API changes, to support these changes like the Topology Manager, we had to introduce additional code to prevent assembly binding errors as you can find here for example).

So what to do when you are on 2013 SP1 and are using DXA, or are planning to use DXA? Well you have several options, the first and foremost of course being, upgrade to the latest SDL Web release. Keep in mind that 2013 SP1 has already progressed to its limited support stage in November 2015, and will move into extended support in November 2017, as per our latest release policy (SDL Web > Web Product Lifecycle). But in case upgrading to the latest SDL Web release is not an option for you, then you have the following two options:

1. Use DXA 1.6
2. Modify DXA 1.7 to compile against 2013 SP1

I would recommend option #1 for most, but in case DXA 1.7 comes with features or fixes that you really need, then option #2 is something you might consider. Technically there is a third option, which is to modify DXA 1.6 and add the features and fixes which you require, which is probably similar in the amount of work you need to do for option #2. It all comes down to this, DXA is open source, and you now have become dependent on that model to make the modifications you require yourself.

When to upgrade your DXA implementation

The biggest question which might rise now is, when should I actually consider upgrading to the newest DXA release? It makes sense when you start with a new DXA implementation, that you base it on the latest available DXA release, but if there is a new minor release roughly every quarter, does it make sense for you to keep up and upgrade your implementation every time? While it makes sense to try and stay up to date with the latest release, I will also agree to the fact that a DXA implementation which is running in production should not remain under development continuously. As a customer/user of DXA, you will have to determine the value of each new DXA release yourself and decide if that value is enough for you to warrant the additional work of upgrading to that release.

The cost of upgrade is basically determined by the level of change we introduce. How much of our public API has changed (i.e. did we break backwards compatibility), and how easy is it to adopt those changes. In the past we have been focusing on keeping the cost of upgrade as small as possible, but because we were growing DXA, you sometimes have to make tough decisions on this. Once we release DXA 2.0 (the merged DD4T/DXA version) we plan to make upgrades to upcoming minor versions a lot easier, since one of the main goals of DXA is to reduce the total cost of ownership. But still it will always remain a question, is the value of a certain release enough to warrant the additional work to upgrade to that release.