So think about this from a Semantic Versioning perspective.  A major version number like 8.0 has a certain implication in terms of breadth of feature changes, compatibility with prior releases and other items.  This is a big deal and only happens every couple of years for most product.  Minor version numbers (7.4) generally indicate new features and bug fixes, but breaking changes are not expected.  Revision numbers (7.4.1) indicate bug fixes and possibly minor enhancements and no breaking changes.

For the Evoq 8/DNN 7.4 launch we had a situation where Evoq had a lot of new features and capabilities.  We changed the name of Evoq Social and instead of being a separate product from Evoq Content, it became our top level product.  We also added substantial new capability in Evoq with the introduction of a new page editing model, page level workflow, a new Content Manager persona, Personalization and much more.  This was a release well deserving of a major version change.  However that was not the case on the platform side.  DNN 7.4 was a big release, but we didn't have the big earth shattering changes that are anticipated for DNN 8. We had a new workflow API, some multi-language changes and a few other changes.  If you look at the release objectively and forget about Evoq, there is nothing to suggest that Platform should have been named DNN 8.0.  It just wasn't there in our lifecycle.

I believe we did the right thing by our customers in splitting the version numbers so that customers knew exactly what to expect with each product.  With Evoq 8.0 they were getting some really stunning new capabilities and with DNN 7.4.0 they were getting some nice new features on a pretty stable platform.

This situation will be exactly reversed in the upcoming DNN 8 release.  DNN Platform will have lots of exciting new features (MVC, SPA modules, WebAPI OAuth support, Dynamic Content Creator, etc.) and a handful of breaking changes.  Meanwhile Evoq will have a few small features and lots of bug fixes.

From my perspective we should do what is right for each product and name them appropriately based on what is in the release.  Arbitrarily keeping versions in sync breaks the whole idea of semantic versioning and doesn't appropriately convey the scope of the release.

---

Joe Brinkman
DNN Corp.

Joe,

Thank you for your input. I understand that from a development standpoint your argument makes sense. However it only really takes into account one side of the equation, namely DNN's side. Think of it from a customer's perspective and a module developer. A Module Developer created a app using the DNN Platform 7.4.1, publishes it and put in their documentation for those purchasing it that it is compatible with v7.4.1. Now anyone running the basic DNN Platform (CE) will have no problem in determining if the module will work for their system.

Now a customer running Evoq 8.0.0 comes along wanting to purchase the same module. If the customer is not aware that DNN/Evoq versions are different, they will simply assume that v7.4.1 is less than v8.0.0 and should be compatible. But DNN v7.4.1 was introduced (from my understanding) with Evoq v8.1.0. I have not tested this but I do know that in the previous incarnation of DNN when it was called CE & PE respectively, it would not install claiming a version incompatibility. I assume the same would happen here. There is no indication anywhere what "DNN Platform" Evoq is based on, so how are people to know when purchasing modules what will and will not work? The separation of version number between the two products has now made for a very confusing situation for customers and developers.

Similar problem would be if a developer is using Evoq v8.1.0 to develop a module, they post that it is compatible with DNN v8.1.0. Those running DNN Platform 7.4.1 have no idea that this would actually work for them as it is the same platform. They simply see a larger version number and assume incompatibility.

There really needs to be a clearer understanding of the versioning, either they need to match (which would be the easiest solution visually), or there needs to be a public and very visible mapping available to customers to understand the Platform/Evoq version relationship. Even looking at the Dashboard on Evoq, the version displayed is that of Evoq and no where do you see which platform it is based on.

---

Ben Santiago, MCP Certified & A+ Certified
Programmer Analyst
(SQL, FoxPro, VB, VB.Net, Java, HTML, ASP, JSP, VBS, Cognos ReportNet)