All, On reflection, we (Don and I) think we've asked a question that has too many assumptions behind it that are not universally agreed. Perhaps we would do better to look at the slightly more general issue. The question we asked about API stability in minor releases already assumes a lot about the frequency of major and minor releases and indeed what a major or minor release actually is; what their purpose is. We've actually started out backwards, we've assumed major and minor timetables and a version number scheme and then asked everyone what should fit that. Instead we should agree what the purpose of Haskell Platform releases are. Once we have decided that, then working out how frequent releases should be and the precise rules and version number schemes will be details that will be much easier to agree. So, what is the purpose of platform releases? Remember that we already have a system whereby any maintainer can make releases of their packages at any time and end users can download and install those releases. So what is the additional purpose of platform releases? * Bundling everything into nice easy end-user installers. This is certainly one purpose. For achieving just this we do not need anything more than a working snapshot of packages from hackage. * Testing. Making sure a set of packages work together. * Getting new features into the hands of users. Not everyone wants to download the latest and greatest from hackage. They want to use things tested together but still want new stuff occasionally. These points we think we all agree on, but none of them really tell us much about how frequent releases should be, as long as they're not so far apart that it defeats the third point about getting new features into the hands of users. * Telling distributions what they should package and telling users what they should have to be able to run the majority of relatively recent Haskell code. These are two purposes but closely related. * Telling developers what set of libs to test against to maximise their potential audience. These are about trying to make sure that users and developers are using the "same" stuff so that people can write programs and know that other people can run them. These require that the releases are the "same" between various operating systems (which the first 3 purposes to not strictly require) but more so that they should be the same between many users and many developers over some non-trivial period of time. This is the stability argument. If we agree with these purposes then we have to consider the balance between stability and progress in terms of new packages, new features and sometimes changing some things in incompatible ways. Note that these points do imply that new features (even compatible ones) cannot be added too frequently. Otherwise developers will write programs using those new features and users will not be able to run them. We would be asking users to upgrade too frequently. One strategy for balancing stability and change is to compress changes into specific points -- major releases -- rather than trickling them out every month. This is in contrast to Hackage which allows for very rapid change and feedback. * Synchronise crossÂ-package changes. Reduce chaotic transitions, eg switching old-time -> time, or new exceptions. This is more ambitious. This implies some community process to decide on these kinds of crossÂ-package changes and buy-in from package maintainers to follow through on the community decision in time for a particular platform release. -------- So we must consider what we are asking users, distributors, developers and maintainers to do. Remember also that we are not preventing developers from releasing new features in their Hackage releases and that the platform gives end users the tools necessary to get those latest and greatest releases. So in comparison to other systems we actually have a much better release valve for the pressure to get new features to users quickly. Duncan and Don