Over the last several years DotNetNuke has maintained a policy of providing an upgrade path for users running previous versions of the platform.  Only in rare instances will we intentionally break a feature or an API or do something that would cause 3rd party extensions to break.  Customers have expressed to us over the years how important it is to maintain an upgrade path.  This concept is not unique to DotNetNuke.  Various projects and companies will take a different stance on the topic.  I was reminded of this recently with the Windows 7 launch where XP users were forced to make a tough decision – go through the hassle of installing a clean version of Windows 7 and then installing all of their old software and migrating their data (I hope grandpa had good backups), just stick with Windows XP, or move to a competitor.  Even Apple recognized the problem with the Windows 7 approach as evidenced by their Mac vs PC commercials.

Another month, another DotNetNuke release.  With each passing month the Quality team continues to get better at building DotNetNuke in a repeatable manner.  Our processes are becoming more and more automated and our QA and maintenance teams are starting to become comfortable with the processes.  It is a marked change from where we were just 12 months ago.  As a stabilization release, we focused this month on closing out the highest profile issues in the issue tracker.  We continued our efforts to solidify the installation experience and have expended additional effort in adding more error handling to the New Module wizard that was added in 5.2.  One major change in this release is that we are moving away from doing any significant enhancements during a stabilization release.  Occasionally we will have a minor change to existing functionality that is aimed at providing better feedback or otherwise resolving a usability issue.  Outside of these issues we will do our best to avoid introducing any new or changed behaviors which are more likely to introduce new defects into the product.  We do have one significant change in this release in the form of support for the PayPal sandbox which was implemented prior to our policy change.  You can see the highlights from this release below.  As usual, you can review the ChangeLog for complete details.

At OpenForce ‘09 we made a lot of announcements about changes to the DotNetNuke project.  One change that we announced was a commitment to provide more regular releases.  Over the past several years we have always focused on making releases when the software was “ready”.  This policy worked well when the project was staffed by volunteers as planning for fixed release dates is extremely difficult when you don’t know from week to week who would be able to work on the project, or how much time they would have available.

In software development, there are 3 major levers that you have available to manage a release given a fixed set of resources:  Time, Scope and Quality.  In general, we don’t feel that quality is a factor where you can cut corners.  This only leaves time and scope as levers you can use when preparing a release.  In the past we have worked on a somewhat fixed scope and fixed quality philosophy.  We tried to determine the features and bug fixes that would go into a release and keep testing until we felt that the software met the desired quality.  In 2010, we have shifted this approach and are now working to fixed release dates with a desired quality level and will adjust the scope as needed to ensure that we can meet our time and quality commitments.

This past year I had the pleasure of being asked by Jim Minatel at Wrox to write a Wrox Blox covering the basics of jQuery for ASP.Net Developers.  Having co-authored 2 previous books, I realized that writing a book, regardless of the size, is a lot of work, but something that I also find gratifying once you have a finished product.  Over the last 2 years, I had gotten more and more into jQuery and really loved its simplicity and power, and thought that this would be a great opportunity to share some of the knowledge I had gathered.

For those that are not familiar with the term, a Wrox Blox is a short e-book (30+ pages) which covers a narrow topic.  They are not intended to be an exhaustive discussion of a topic, but rather to cover one particular aspect of what is often a much broader subject matter.  Because of their narrower focus and the fact that they are only available as e-books, Wrox is able to keep the cost of the Wrox Blox very low.  Wrox Blox generally include a lot of code examples rather than being a purely theoretical discussion of a topic.

After a couple of months, several missed deadlines and a page count that greatly exceeded what was originally requested, I finally finished the Wrox Blox which was subsequently published last September.  I am very pleased with the final product which comes in at 66 pages and is a great introduction to jQuery and ASP.Net.  jQuery for ASP.Net Developers  includes sections on the jQuery API and its usage, and on using jQuery with ASP.Net WebForms and ASP.Net MVC frameworks.  I had a great time writing the book and like all writing assignments of this size, it really forced me to dig into jQuery much deeper than I had previously.  It also gave me a greater appreciation for why Microsoft chose to ship jQuery with Visual Studio 2010.

I don’t know if any else is like me, but occasionally I will run across something on a website and think that if only I could make some little tweaks to the site, that I might be able to make it more suited to how I think.  Maybe it is just a bit of CSS that might clean things up a bit, or maybe if I could just re-arrange things on the page I would have an easier time finding that awesome feature that always seems to get tucked away in a hidden corner of the page, never to be seen again.

I was on the DotNetNuke forums this morning and noticed that Chris Paterra had added a new “Quick Reply” feature.  This is a simple textarea and submit button that was added to the bottom of the forums page.  The nice thing about the quick reply is that I don’t always need fancy html or the ability to pin the post or any of the other features that are on the regular reply page.  Using the new Quick Reply, I can easily post a response without any visible postbacks.  This is a much nicer Web 2.0 experience and something that I am sure many users will love.