As we work to introduce new features, such as the improved upgrade process, or do regular maintenance with DNN Platform, we sometimes have those items that we did not expect to appear when a release is completed.  As we have been discussing in other updates, sometimes we learn about these AFTER a release makes it out, and then our hands are a bit tied on how we can move forward.

Do we leave the issue and document a workaround?  Well, we can, but historically, that hasn't provided a great user experience.

Do we update the release for future users? This is actually no longer possible given that GitHub has made releases immutable (Unchangable) for security and related purposes.

Do we simply encourage users to "Skip the problem release?" This is our traditional stace, get a new release out quickly and then have that new release be the suggestion!

Ok, So Why 2 RC's This Time

As we work to improve the upgrade experience, it is important for us to provide a pathway for users to get from 9.13.x -> 10.2.x so that future upgrades can utilize the new upgrade process.  DNN 10.03.x and later have changes that require the new upgrade experience to support a good user experience.

After releases went out, it was discovered that 10.02.03 had a few issues that prevented upgrades from completing in certain circumstances.

DNN 10.03.00 additionally had an unexpected breaking change for certain users of XSLT menu templates.  

So, to ensure that we have a CLEAN upgrade path, AND that those that are upgrading have a solid landing point we have 2 RC's going on concurrently.  10.02.04 RC1, which will then make the official upgrade path 9.13.9 or 9.13.10 -> 10.02.04 via the traditional upgrade path, and then the new process going forward.  10.03.01 RC1 was created to ensure that those upgrading and testing the new experience have a good result!

Happy testing!  And here is to continued improvements for DNN Platform!