Over the last four years DotNetNuke has experienced tremendous growth and adoption. We have added more features to the core and grown the project teams to the point where there are now more than 45 people actively working on one DNN project or another. At the same time we have also grown the programs around the project that help fund DotNetNuke and provide support to the community - programs like the Benefactor Program, the Review Program, the MarketPlace and the upcoming OpenForce Conferences.
The downside to all of this growth is that the processes that worked for our 1.x releases are no longer adequate. Our current release processes are not optimal for the project as it exists today. Over the last year, we spent a lot of time fine tuning our release processes for modules. We have not given this same level of scrutiny to the processes we use for the core releases. That is changing. We recently started working on formalizing the processes we use for core releases. These process will cover the entire development cycle from requirements gathering through release. The processes will detail the tools we use and the manual steps that must occur throughout the development cycle.
One of the projects biggest challenges over the last couple of years has been communications. This is especially challenging with respect to project releases. Until the processes and tools are in place to manage the release then we will not fully solve the communication issues. It is not as simple as saying post release information "here". You have to identify the information to be posted and then find out who has the information. It does not always reside in a single location. What is the status of DNN today? If you asked that question of every member of the DNN core team you would likely get completely different answers. 
This is why answering a question like "When will DNN be released?" is not currently possible. Nobody has the entire picture to be able to adequately answer the question. We do not have a method in place to bring all of the various pieces of data together in order to get a snapshot of where DNN stands in terms of our current status. What bugs have been found in testing? Have we had enough testing? Are these existing bugs or are they regression issues? Do we need to go back and fix code for a feature/enhancement/bugfix that introduced new problems or that didn't properly correct the previous issues? Even once coding is done, we need to determine if the code has been dogfooded and if the new release package has been built. Have our marketing items (press releases, blog posts, newsletter) been created? Is the documentation up to date. Currently, there is no person on the team, not even Shaun, who has the answer to all these questions at any given point in time. The result of all of this is that determining the release date is so difficult which means we often don't adequately communicate the project release status to the community.
One of my many project tasks is to straighten out these processes and get the tools in place so that we have a unified view of the project that will allow us to consolidate all of the information in a single place, thus making status determinations possible. Over the next 6 months or so we will be making small incremental changes that will be immediately visible to the community (some of those changes will be directed at the testing group and will not generally be visible to then entire community). Prior to starting work on the 4.5.4 release, we added a roadmap module to allow the community to vote on the implementation priorities for roadmap items. For the 4.5.4 release we started using a new test tracking module to determine the level of testing that is occurring. 
Following the 4.5.4 release, we updated the downloads page to make the change log more visible and have added a new timeline to the release schedule page so that the community can better see the anticipated release schedule. We are also planning on implementing the release tracker that we have been using for the various projects. These items are not currently in their final forms but will provide us a good foundation in order to get community feedback. Eventually all of these items will grow into a set of modules that will provide us the necessary tools to manage our entire release process and provide the appropriate visibility into the project status for the community.
The release process is an important part of the project that has been neglected over the last four years. We are aware of the shortcomings and realize that it will take a concerted effort over the next several months to get a more formal process in place that adequately addresses the needs of the project and the community while also recognizing that the process must remain flexible. We have taken some small steps so far and have many more steps to go before we are satisfied. Implementing the new processes will not occur without some growing pains but we believe that the end results will be worth the effort.
One of the hallmarks of every successful Open Source project is constant change. Over the life of the project, the code grows and changes based on the needs of the community. The team and the way it is organized changes to accommodate the needs of the project. The same should be true of the processes used for developing the code and managing the project. This has certainly been the case with DotNetNuke and something that we should keep in mind as we develop the new release processes. While we will eventually achieve stability in our processes, we need to be constantly evaluating those processes to ensure that they continue to meet our needs and we have to be more willing in the future to change those processes as soon as they become outdated rather than waiting as long as we did this first time.