I think in the interests of clarity and simplicity we should avoid any API changes, even additions, in minor releases. If this means that major releases need to be more frequent than 6 months, then so be it; but we really don't want the complexity of two layers of API-changing releases. However, I'd like to argue for sticking with 6-month major releases, or at the very least 4 months. The benefit of the platform is that we get a set of compatible and well-tested libraries as a single unit, and the closer together the releases are, the harder it becomes to deliver that. The more frequent the feature releases are, the lower the overall quality: new code introduces new bugs, there needs to be enough time to stabilise. We've found in GHC that we can just about manage 12-month feature releases, and even then we often ship with some nasty bugs. Partly this is due to lack of manpower, but also it's down to the lack of testing that pre-releases get - it typically takes us about 6 months to get to a nice stable state after a major release. One disadvantage of the platform is that we might even see *less* testing of the early revisions in a new GHC release, as people stick to whatever comes with the platform, and the platform might be slightly conservative about taking new GHC major releases. In the future I'd like to aim for full ABI compatibility between minor releases. Various people have heard me rant about this before so I won't do it again (especially when the plan is still not fully formed); suffice to say that I think it should be possible to make it such that upgrading to a new minor revision of the platform doesn't break all the other packages you have built and installed using Cabal. Now, while technically speaking it's possible to allow API additions and still maintain compatible ABIs, I don't think we want to deal with that, at least not initially. For cutting-edge programmers who need more recent APIs, there is always Hackage and cabal-install, which work very nicely. Cheers, Simon