A common open source concept is referred to as "release early, release often." The justification is that the sooner you release, the sooner the open source community can validate the functionality, and the sooner you get feedback — good and bad — which helps improve the overall product. This concept is often combined with a "public daily build" paradigm, where continuous integration is used to automatically build, package, and publish a new application version every day. These concepts make a lot of sense for single-purpose applications; that is, applications that have closed APIs and have no external dependencies. But plug-in framework applications such as DotNetNuke possess a different set of requirements, many of which are not complementary with the "release early, release often" model.
Consider the case of any entity that has developed plug-in resources for the DotNetNuke framework. These could include modules, language packs, skins, or providers. Every time a new core version is released, each of these resources needs to be validated to ensure that it functions correctly. In many cases, this involves extensive testing, packaging a new version of the specific resource, publishing compatibility information, updating related documentation, communicating availability and/or issues to users, servicing compatibility support requests, updating commercial product listings, and so on. You must also consider the issues for the resource consumer. Consumers need to feel confident in the acquisition and installation of application resources. They are not keen on analyzing complicated compatibility matrices to manage their investment. And resellers such as Hosters represent an even larger superset of application consumers. The effort involved to perform application upgrades becomes more complicated and costly as the release frequency increases. This is clearly a case where "release early, release often" can lead to issues for framework consumers and suppliers.
For these reasons, DotNetNuke has always tried to follow a fairly well-structured release cycle. This has resulted in fewer major public releases but a much higher quality, more stable, core application. In general, it has enabled DotNetNuke resource suppliers and consumers to participate in a functional product ecosystem. However, as the number of serious platform adopters increased, so did the demands for better core-release communication.