Software is Hard
Building software is a challenging business. That is one of the things I like about it. There is always a new obstacle to overcome or new technology and techniques to better solve an old issue. In short, building software is like solving a giant puzzle that has multiple correct answers. Some of the answers may require brute force or crude techniques where others may be elegant in their simplicity.
There are never any shortage of challenges in software development. Even when your own code works correctly, sometimes external factors can conspire against you and create new challenges.
DotNetNuke is a complex piece of software that includes many different components. Most of the components are developed by the DotNetNuke team, but a few are developed by external parties. These external components provide needed functionality and allow the DotNetNuke team to stay focused on building a great CMS and not get too bogged down trying to build the perfect zip library, or an MVP framework, or a comprehensive suite of server controls. In addition, DotNetNuke relies on an entire stack of software on both the server as well as on the end users computer. All of these external components are constantly changing. On occasion, changes in the underlying components will result in problems with your software. Such was the case with the recent DotNetNuke 5.6.2 release.
The Web is Constantly Changing
March 2011 was a very big month in the web development world. Almost all of the major browser vendors released a significant new browser version within the span of 30 days. Some of those browsers, like Chrome and FireFox, didn’t introduce any significant new issues that impacted DotNetNuke. Unfortunately, the same was not true of Internet Explorer.
Internet Explorer 9.0 includes major improvements over previous versions of IE. IE has long had a poor reputation in the web development world because it didn’t always do things according to the standards, didn’t fully implement standards, or was plain buggy in its implementation. The end result is that developers often developed workarounds in their software to deal with the quirks of IE.
IE9 tried to improve on all fronts by adhering closer to the standards, adding support for missing pieces of the standards and fixing some of the bug-ridden areas of the platform. It was definitely an improvement over all of the previous versions (although there is still plenty of room for improvement). Unfortunately, all of these changes resulted in issues for many web applications and components since some of the workarounds and hacks used for older IE versions were no longer required, or would actually result in incorrect behavior in IE9.
Many software companies do not put much effort into fixing browser specific issues while the browser is still in a pre-release mode. It is very easy to chase bugs which are transient and which will ultimately be fixed in the browser and not require any work on your part. Usually, web development companies will identify issues, and wait for the browser to be finalized before releasing an updated version of their own products. In this regard DotNetNuke is no different.
Of course, the week we chose to release DotNetNuke 5.6.2 turns out to also be the same period when Microsoft released the final version of IE9 and the same time that Telerik released a new version of RadControls for ASP.Net AJAX that addressed issues with IE9. The new Telerik version did not come out in time to get through our internal testing and be released in DotNetNuke 5.6.2.
Improvise, Adapt and Overcome
Our original plan was to ship the updated control with DotNetNuke 6.0 which is due out in a few months. For some people in the community, this was not a great solution. DotNetNuke 6.0 will have a lot of changes and may have issues which prevent customers from upgrading. There was a chance that customers would be forced to live with their current DotNetNuke installations until late summer or early fall when the 6.0.1 and 6.0.2 stabilization releases are expected to be release.
The entire DotNetNuke team is currently focused on getting DotNetNuke 6.0 ready for release. This is the most significant release DotNetNuke has had in 5 years and it is consuming all of our efforts at the moment. We definitely do not have the extra manpower needed to create a whole new release package and take it through the QA process just to address this one issue. In speaking with members of the communities yesterday, I was reminded that we have the ability to solve this issue without requiring a whole new release.
One of the great strengths of DotNetNuke has always been its extension packaging system. It is relatively painless to install new DotNetNuke extensions. We have an entire eco-system that is built around creating, packaging and shipping extensions to the platform. Users are accustomed to installing new modules, skins and other extensions.
Because of some of the challenges we encountered during the DotNetNuke upgrade process when shipping with new versions of Telerik assemblies, we were forced to package the Telerik assembly as an installable library. This allowed us to ensure that the web.config was properly upgraded along with the assembly, and ensured that users could safely upgrade their systems without errors.
This morning, after having completed some internal testing late yesterday and last night, we uploaded the new Telerik install package to the DotNetNuke 5.6.2 downloads page on CodePlex. Those people who want to patch their installs, can do so by installing the new Telerik library from their Host >> Extensions page of their DotNetNuke installation. This is the same library that we expect to ship with DotNetNuke 6.0 and should not cause any difficulty when upgrading to the next version of DotNetNuke 6. This library has only been tested with the 5.5.x and 5.6.x releases and should not be installed on any prior releases without conducting your own testing.
NOTE: As with any release, we recommend you perform a complete file and database backup before performing any installation on a production website and that you first conduct a trial installation on a staging version of the site. Following these guidelines will ensure that you are able to recover should any unforeseen problems arise during the upgrade process.