I have had this blog posting all ready to go now for a good three to four weeks, but have been in a deep internal conversation in regards to the posting of the article. I have decided that more than anything posting this publicly might stop some of the e-mails that I get bombarded with each and every day that starts out with "what do I do" or "do you still believe in DNN".
Before I start the post I am not in any way, shape, or form pointing fingers or expressing any displeasure at the platform or any of the members involved. I am still a DotNetNuke core team member, I believe fully in the platform, and I will continue to adopt and recommend the usage of the platform for the foreseeable future. The point of this post is very simple, to talk about what has been going on in the DotNetNuke community and my opinions on how to manage expectations and cope with the situation. Please remember the disclaimer that is posted at the bottom of this blog, these thoughts are mine and mine alone.
The Problem
To start out I want to clearly outline what I am talking about when I am talking about "growing pains". As many of you have become well aware, there have been a few releases of DotNetNuke that have gone out in a "less than stellar" release pattern. Most specifically the critical releases were 5.3.0 which prompted a very quick 5.3.1 release this March, the second one is the most recent release of 5.4.3 which just yesterday was pulled from download.
It is situations like this that can cause site administrators and other adopters of the platform a lot of grief. In the case of the 5.4.3 release, it came out on 6/17 and was pulled on 6/21. Yes a small amount of time, but what about the users that upgraded? That is where we are going later in this post when I discuss "how to cope".
The Cause
By now I think Joe Brinkman has done a pretty good job of educating the community that the corporation is experiencing some growing pains. They are actually sticking to a release schedule, pumping out more and more functionality than ever before and all in all it is going well. However, with any and all progress, there is always that little setback or speed bump that gets in the way. I think this is what we are experiencing here, in each of these cases the major point of the issue has been with integration points for third-party extension developers, while although a key feature of DNN it is an aspect of the core that is very hard to test.
Common Questions to Me
As soon as the DotNetNuke 5.3.0 release issue occurred earlier this year I was almost instantly seeing more and more e-mails that went along one of a few trains of thought: "Do you still believe in DNN?", "We can never trust a x.x.0 release!", and "Does DotNetNuke just not care anymore?".
I will start by discussing each of these common trends, as honestly, these are key points to how I cope with this type of situation.
Do you still believe in DNN?
Yes, I still fully believe in the DotNetNuke platform and believe that they are making progress to keep the software moving forward, they have grown at an amazingly large pace and there will be the occasional issue here and there, but I still believe that DotNetNuke is the BEST ASP.NETApplication Framework available and continually recommend it and implement it for my sites and those of my customers.
As with any software development company, there are times that releases are better than others, this is the same story for those large and small. Even Microsoft has their releases, items like Windows ME and Windows Vista are typically the most comment references.
We can never trust a x.x.0 release!
Now, this is one where I am going to go off a bit on a tangent. In my opinion YOUCANNEVERTRUSTARELEASE. Now, before everyone gets upset with that statement, let me explain this a bit. My point is you should never just trust a release because someone else says it works. You should be testing the release yourself, do an upgrade of a test installation and make sure that your environment is working properly BEFORE you upgrade that critical site.
Each and every DotNetNuke installation is different. You might be upgrading from a really old version, a new version, you might have tons of third party modules that are outdated or you might have that one "problem child" module. The key to mitigating upgrade risk is to do your own validation, regardless if it is a major release, a minor release, or a point release, NEVER simply "upgrade" and when you do upgrade TAKEBACKUPSbefore you start as even with the best testing in the world things can still go wrong.
Does DotNetNuke just not care anymore?
This question is a tough one, knowing the DotNetNuke Corporation people and knowing what they have given to make DotNetNuke what it is today I find it hard to believe that this question would even come up. I can only imagine how hard it has been for Joe and others to create the communication necessary to document these issues, and how much time they are most likely spending answering questions to the guaranteed masses of people that have been pinging him directly.
Although there have been issues I would hope that the swift actions to pull releases and get fix releases out to the community show the dedication to the community and the product. The improvements that they are talking about making are going to go a long way.
How I Cope
Now that I have helped lay out what the issues are, I thought I would share a bit about how I manage to limit my exposure risk to these types of issues.
Allow Any Release to Stabilize
First and foremost, every time a new release of DotNetNuke, or most other products for that matter, I always wait for at least 2-3 weeks before I will upgrade ANY website. During this period I will test upgrades and work on validation of my systems to know if the upgrade will be possible. I will also keep a close eye on the forums and other communication channels to see if there are any regular, repeatable issues that have been identified. By doing this, situations such as the 5.3.0 and 5.4.3 releases would not impact me, as the major issues came up well before 2-3 weeks.
Upgrade Only When Necessary
With the more frequent release schedule of DotNetNuke, I am really supporting an "Upgrade When Needed" process for upgrading. With monthly releases your average site would require 12 upgrades in a given year, this is TOOfrequent for most sites, and it is typically not needed. With each new release, I will review security bulletins and other release notes to see if an upgrade is truly necessary. In most cases I do not see a need to upgrade, in-fact some of the most heavily trafficked sites that I run are NOT updated as frequently as others.
Don't Do Blind Upgrades
If you do decide to do an upgrade, be sure that you are fully aware of what is going on. Review the upgrade log, test the site, don't just pull up the homepage. Click around, go to host settings, go to admin settings, and touch each of your custom modules. If you took proper backups BEFORE you did the upgrade and you quickly go through major functionality of the site you can roll back the site if issues are identified and suffer a minimal loss of data and site functionality.
Help Out
DotNetNuke Corporation has been working a lot recently to more openly solicit feedback from the community. This feedback includes bug reports, bug fixes and any item in-between. If you are a developer and can spare some time try going to Gemini and submit a fix for a big. If you don't have development skills but identify an issue, post it to Gemini, put as much information as you can so it can be re-created, then someone can work on getting the issue resolved.
I understand how hard it is to spend the time, but spending a little bit of time giving back goes a long way, and is a very productive way to express feedback.
Conclusion
I hope that this has helped give my perspective on DotNetNuke. Don't give up hope, just follow standard processes to properly leverage software and you will be fine. Feel free to share your comments below.