For the last 4 months, stabilization releases have been just that.  It is not new enhancements that are breaking.  It is basic functionality where a bug fix is causing new problems.  For example, in this case a bug fix to resolve a problem on the SQL screen for a new feature added in a recent major release resulted in an ambiguous method overload (5.4.2).  The ambiguity occurs because of the ParamArray parameter in ExecuteSQL which really equates to multiple implicit overloads.  The implicit nature of ParamArray meant that you could have cases where the modified code would work in one case (as it did during our internal testing), but then fail when called by an external module.  During the subsequent fix in 5.4.3, the developer did not pay close attention to maintaining binary compatability.  This is something that has bitten almost every developer who has touched the core.  It is very easy when changing code to get focused on a particular bug and not keep the big picture in mind.

In the end I think we all recognize the value of stable, well-tested releases.  The problem is how to get there from here.  Part of that involves changes in how we develop software, changes in how we engage the community, and changes in how we validate that we are ready for a release.  Many of these changes have been underway for several months and some we are just getting started with.   None of the changes are easy and few will occur overnight, but we are making progress even though at times it seems like we keep repeating the same mistakes.  As the guy who ultimately puts out each release, and has to explain when things go wrong, I am acutely aware of how difficult it is for everyone involved.  Thank you to everyone for your input.  I know we are all on the same side in wanting to see DotNetNuke continue to excel.  With your continued help and participation in the release process I am sure we will see rapid improvement in the quality of our releases.

---

Joe Brinkman
DNN Corp.

My reading of the posts to date is that yes we want frequent releases but they have to work as expected.

We need suggestions on how to improve the reliability of the releases. How can the general community assist in this process?  Can we spread the testing workload more?  Maybe we can have a published set of tests that users (not necessarily devs) can do both on core functionality as well as 3rd party modules and a system spreads the testing so as much as possible gets tested and reported back.  The community members involved would gain some sort of reward for their time, either in recognition or product as an example.

There haven't been many posts from a 3rd party module developer point of view. It would be interesting to hear from some of the more active/prominent 3rd party developers how much time it takes to test their modules against new builds and how the monthly release impacts them. How? Can the community help them and if so how?

Antony

I run the Community QA Team and asked for volunteers a few months ago and got a few responses.  Out of that we have one new Volunteer Dan Gilleland who deserves a mention for the stellar job he is doing on writing the unit tests for the new Testable DNN Module template we are creating. 
I would really love a couple more people who would like to help out with testing of DNN. 
Firstly we need some devs to help write more automation tests, currently we have automated tests for about 40% of the core functionality. 
Secondly I'd like a couple of people to run a set of manual tests, if you're a  third party extension author even better.  We could write some manual and automated tests to test your module.

If youre interested please see http://www.dotnetnuke.com/Community/T...

Cheers

---

Philip Beadle - Employee