DnnInstalled - It is a great sentiment to hear calls for regression testing and dogfooding; For us to spend more time getting a release correct. But clearly not everyone in this thread shares that opinion. In fact 4.5.3 did not add NEW bugs as far as I can tell. 4.5.3 was created specifically to address a very narrow range of bugs which were of such a critical nature as to make 4.5.2 unuseable for a broad segment of the community.
Even with the limited nature of the 4.5.3 release, we still have others in the community complaining over other fixes that were not added to 4.5.3. In fact the whole point of this thread seems to be give me 4.5.4 as quickly as possible - consequences be damned. When I hear calls demanding that we give a date for 4.5.4 it really gets the blood boiling. The same individuals will 1) Complain when we miss the date 2) Complain when we don't fix bugs according to their priority 3) Complain when the release goes out and has additional bugs.
So what is our plan and when will we release 4.5.4:
1) The first order of business is to get a complete picture of which items need fixing. This does not happen in one day or even one week. We need a couple of weeks minimum from a previous release to get a full picture of what the major bugs are in relation to the latest release. Get those new bugs entered into Gemini. Prioritize the new bugs with the existing bugs that did not make the cut for the previous release.
2) Once we have a fairly complete picture, then we can prioritize our work and create a scope for the next release. In this case, the general scope has already been determined - the next release will focus on bug fixes. We may have a couple of minor feature enhancements and refactorings to address items which were already slated for the next release, but I don't believe that there will be any new features.
3) After we have a scope then we will create an internal target date for the release. Generally speaking, at a minimum we aim to have at least one release every quarter. We believe that 2 or 3 month release cycles are optimum for both the team and the community. If we release too often then the developers become burnt out. If we release too infrequently then the community suffers.
4) As we approach our target date we will start scheduling the expected beta period and targeted GA date. These are still a little fluid as we may have additional bugs that pop up either prior to beta or during beta. This will necessarily require us to change our target dates.
5) Once we have what we believe is a stable and solid release candidate, then we will begin dogfooding the release on DotNetNuke. Past experience tells us that we need approximately 1 week of dogfooding before a final release. If we are dogfooding an incremental release candidate then the dogfooding phase can be much shorter since the scope of changes are much smaller (note: this is exactly why we only dogfooded 4.5.3 for mere hours before the release).
6) When we are comfortable that beta is proceeding as planned and that we have no big surprises, and also assuming that the dogfooding has been unremarkable, then we will publicly announce an expected release date.
There is more to the process which I have not touched on but to answer Brian's original question: We will give you a release date when we have completed steps 1 through 6 above. Or, as someone else has already said - we'll release 4.5.4 when it is done.
Now there are a couple things to note here. For our next release we are creating a formal position for the release manager. The release manager will be working to formalize our core release processes so that they are repeatable, release after release, with an emphasis on process improvement. The first step however, is just to get basic processes in place and then work from there. We will be looking at a more formalized testing method, because clearly, what we are doing now is not working. The release process will also work to better enable community participation - both in the ability to submit code fixes/patches and in the ability to particpate in a structured beta testing program.
None of this is meant to imply that we don't currently have processes or that we don't do testing. The problem we have right now is that we are not formalized enough. Without a release manager, focused on this task, then other factors can begin to influence release decisions, whether it is someone from the community demanding a release date or it is some external event with a fixed date (like the impending release of Orcas or the upcoming OpenForce conference).. Also, without this focus, it is too easy for critical process steps to be overlooked and then rushed in order to hit already announced target dates.
We expect this week to have formalized the release manager and his role and will let you know more details as they become available.