The clock is winding down on the DotNetNuke 6 release. All of the features have been integrated and we are now focused exclusively on polishing the app before we ship later this month. At this point we have identified all of the issues we plan to resolve for the initial launch and are working through final phases of the testing process. In order to assist people in planning for a smooth upgrade process for 6.0 we are providing a second beta release so that people can retest upgrades and installations which may have had serious issues with Beta 1. If you find an issue we ask that you enter it in the bug tracker so that we can evaluate whether it a showstopping issue or whether it is something that could be held for our first 6.x maintenance release which we expect to be about a month after the DotNetNuke 6.0 launch.

Over the last 6 weeks, the DotNetNuke team has been hard at work preparing for our first Beta release of DotNetNuke 6. The DotNetNuke 6 Beta does not include a lot of new functionality but does include significant refinements of the features we had previously highlighted during our CTPs. Even as we were putting the finishing touches on the beta release, the team has been actively out promoting the upcoming launch and demoing DotNetNuke 6 at every opportunity. We have used these opportunities to get feedback from the community and have incorporated some of the suggestions into this release.

Today marks another milestone in the upcoming Hadron release of DotNetNuke.   For the first time ever, DotNetNuke is offering a Community Technology Preview that will allow you to begin testing the latest version long before we have completed all the features.  As I discussed last week, the CTP is not intended to be production ready software but is an opportunity for the community to get a chance to start kicking the tires.  The CTP is an important milestone as it will allow us to gather feedback from the community much earlier in the release cycle and thereby allow us more time to incorporate that feedback into the final release.

"What's in a name? That which we call a rose by any other name would smell as sweet." Romeo and Juliet (II, ii, 1-2)

Sometimes a name is everything.  It can convey meaning and emotion.  In the world of software, a name can convey the stability or instability of a release.  The name, or label, that we apply to a release is our way of communicating to you some important information about our product.

Next week, for the first time since DotNetNuke was created, we will be releasing a Community Technology Preview (CTP).  This CTP will be for the upcoming DotNetNuke 6.0 release.  Later this spring we will release another CTP, a Beta or two and a Release Candidate (RC).

Each of these terms (CTP, Beta, RC) represents a specific milestone in our release process and it is important to understand the distinction to know what you can expect in each release.  Most developers in the Microsoft ecosystem will understand the terminology, but this post is intended to be a refresher so that as we discuss these releases in our community everyone will know what we are talking about.  Our definitions may be slightly different than the way it is used by other companies and that is ok, as long as we are consistent in our usage.

Over the past year the DotNetNuke team has been working hard to improve the pace of our releases and to provide the community with the opportunity to participate in beta testing in order to provide feedback prior to a release.  As of this morning DotNetNuke 5.6.2 beta packages are now available for download from our Beta Downloads page.  We have made a number of fixes to the platform and incorporated a couple dozen performance enhancements.  5.6.2 further stabilizes the 5.6 platform and should be a solid foundation for your DotNetNuke site.  Please keep in mind that this is just a beta and is not intended for production use.  Upgrades to the final 5.6.2 release are not supported.  We still have a few additional issues that we expect to be resolved prior to our Mid-March release but welcome any feedback.

The beta release of DotNetNuke 5.6.1 is now available for download on CodePlex.  In the past we have not made public beta’s available for the maintenance releases because there wasn’t much time between when we started QA and when we actually released.  Given the recent change in our maintenance release to every 2 months, and the extra time afforded by the winter holidays, we have decided to release a beta for 5.6.1 so that people have a chance to test what we’ll be releasing in January. 

At this point, the code is pretty stable and we have a very small list of outstanding regression issues we are working on for this release.  You can see the list of outstanding issues on the DotNetNuke Roadmap for 5.6.1.  If you find an issue, please log it into Gemini and we’ll take it from there.  It is unlikely that any bugs found at this point will make it into 5.6.1, but it will give us a good head-start on identifying issues to be fixed for 5.6.2.

Earlier this Week a public version of the DotNetNuke 5.6 Beta was made available on CodePlex.  For information on how you can help with this release and to get access to the current version please visit our Beta Release page on DotNetNuke.com.  In this release we have spent quite a bit of time cleaning up some lingering...

Last night we posted another beta of DotNetNuke 5.5 which you can access from the beta release page on DotNetNuke.com.  This is probably your last chance to provide feedback on the 5.5 release as we are nearing completion of the testing cycle.  You can have a direct impact on the quality of the 5.5 release if you act today.

Since the last beta release 2 weeks...

The 5.3.0 development cycle has been unlike any in our 7+ year history.  In some respects this is good and in others – not so much.  As I explained in my Just Like Clockwork post, we are working hard to make monthly releases a habit and to have release schedules that are predictable.  DotNetNuke 5.3.0 marks the first major release we have attempted since splitting our engineering group into feature development and maintenance groups.  As always, doing anything for the first time can be challenging.

The maintenance group has gotten into a pretty good grove with our monthly releases, but adding an external group into the mix has added an additional level of complexity.  The maintenance group is able to make our changes in a single branch and quickly test, package and release our monthly stabilization releases.  Unfortunately, the feature dev group works in a separate branch which means code merges, integration testing, lots and lots of regression testing and in general a more complex testing and release process.  We certainly have learned quite a bit from this first cycle which we’ll apply to future major releases.

One of the benefits of Open Source development is that you have a lot of community members to kick the tires and make sure everything is working correctly before you finalize a release.  In the past DotNetNuke has limited our beta releases.  Usually it would start with a small internal team and move from there to a selected group of public beta testers.  We generally did not hold wide...