There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton
This is one of my favorite quotes regarding computer science. Currently I find myself facing a challenge that involves both of these issues – Is DNN 7.5 the right name for the next major release of DNN? If we change the name how do we invalidate everyone's "internal memory cache" so that we don't cause confusion?
Let me tackle the first challenge. Several months back, we began looking at where .Net was headed. Microsoft was increasingly talking about ASP.Net vNext, which they subsequently named ASP.Net 5. They did this to signal that ASP.Net 5 would be a substantial change from the existing ASP.Net 4.5 which was released in 2012. When I laid out the roadmap for where we wanted to go with DNN in 2015, I identified two substantial releases – one focused on the existing Web Forms based version of DNN (DNN 7.5), and one focused on an ASP.Net 5 (running the CoreCLR) version of DNN (DNN neXt).
As we have been digging into the work for DNN 7.5 we are finding that the name does not sufficiently capture the full scope of the changes we are making. DNN 7.5 is a significant advancement over the previous DNN 7 releases. Not only are we adding significant new features to the platform, but we are also fundamentally changing how the platform is architected, packaged and distributed.
I am really excited about many of the new features we are adding to the upcoming release. One of the biggest features is the addition of support for ASP.Net MVC. We have had many customers and developers ask us for this feature and I am glad that it will now be available in the platform. You can read more about this in the recent CTP 1 announcement.
In addition to new module types, we are also adding a whole new module and the supporting APIs to the DNN Platform. One of the earliest modules included with DNN was the User Defined Table (UDT) module. This module has gone through a lot of changes over the years and is now known as the Form & List module. In addition to the Form and List module, there are numerous other content modules available for DNN like 2SXC. This type of functionality is a core feature in many Content Management Systems, and as a result we have decided to build the Dynamic Content Creator framework and modules for distribution as a standard part of DNN.
In talking with many marketing users, we have found that providing freeform rich text editors is not always an optimal experience for users. While developers don't mind dropping down into HTML to fix the occasional rendering problem, this is not a great experience for business users. The dynamic content creator allows the content manager to break down content into smaller bits of structured content (a title, an image, a date, a paragraph of text, etc.), which can then be formatted and displayed using a standard template. This allows content editors to focus on the actual content and not on the HTML and CSS to make the content look nice.
The Dynamic Content Creator module will expose core APIs which can be used to manage and display dynamic content. This framework builds on the work we have done for ContentItems so it will have versioning and workflow support on day 1. I am really looking forward to seeing how the community uses and extends this new feature.
In 2012, we released the Web Service Framework as part of DNN 6.2. That framework was always intended to be the first step in delivering a secure REST API for managing your DNN installation. Since that time, developers have also been asking for a way to write their own secure web services that are accessible from external applications and websites. In the upcoming release we will finally deliver on both these promises.
In CTP 2 & 3, we will deliver both HMAC and OAuth 2 based authentication for web services. Each authentication type covers different scenarios and will ensure that developers can create secure web services that best suit their desired usage. HMAC works securely over HTTP connections but requires end users to create an API Key and API Secret for their account. OAuth 2 requires an HTTPS connection but doesn't require any special configuration of the user's account. With these two authentication options I am confident developers will have a solution that meets their needs for creating secure web services.
In DNN 7.4 we added a new workflow API to the core platform. In the upcoming release we'll complete our work and add a new Workflow manager to the platform. The workflow manager will allow specified roles to create and edit workflows including specifying roles and users with approval authority. These features have long been available in Evoq Content and with this release, this capability will now be available in the DNN Platform.
For the last decade we have referred to DNN as both a Web Application Framework and as a Content Management System. Due to the way DNN has historically been packaged, we often had to compromise on both fronts. People who just wanted a framework were forced to install all of the CMS features, even if they were unneeded and unused. Conversely, CMS users often had to download and install additional extensions to fully satisfy their content management requirements.
In the upcoming release we will separate many of the CMS features from the underlying platform. The platform will provide some minimal UI along with the core platform API. Users who desire a full featured CMS will be able to download the standard pre-packaged CMS distribution, or even a customized community distribution that is better suited to their particular needs. Since the administrative modules will be packaged separately, you'll even be able to swap out individual admin modules for a completely customized installation.
Announcing DNN 8.0
These features and enhancements are just a few of many changes we have planned for the upcoming release. It is clear with all of these enhancements that the DNN 7.5 name does not adequately convey the full scope of the changes we are making. I am happy to announce that we have decided to change the name to DNN 8.0.
Changing the name is not just about signaling the size and scope of the upcoming changes, but it is also a signal of our ongoing commitment to the DNN Platform. Later this year Microsoft will be releasing the new ASP.Net 5 platform. This release is a complete rewrite of the existing ASP.Net MVC, WebAPI and SignalR frameworks. There are a lot of great features coming in ASP.Net 5 and I think it is important that DNN users have options for staying with the current web forms based platform or moving to a newer platform that fully embraces ASP.Net 5.
This spring and summer you will begin to see more community discussions around what this new platform version looks like, what features it carries over from the existing platform and what new capabilities it provides. Even as we begin detailing our plans and efforts for ASP.Net 5, it is important that our existing DNN users understand what this means for the existing platform.
DNN 8 will not be the last major release of the Web Forms based DNN Platform, but rather the continuation of a platform that we expect to support for years to come. Ultimately, DNN Corp will continue to support DNN 8 and the Web Forms based platform for as long as the community finds value in the platform and is willing to work with DNN Corp. to maintain and enhance the platform.
As Phil Karlton points out, naming is hard. Hopefully, with this change we have a name that is more indicative of what we'll be releasing with DNN 8. Now if everyone would kindly disregard that we ever called it DNN 7.5 and we'll have solved both hard problems.