Duncan Coutts wrote:
It's clear that bug fix only doesn't cause major compatibility headaches (if done sanely) . It's obvious that API breakage causes upset.
Indeed. (Relatedly, one detail not covered by the PVP is the issue of "strictness bug fixes". Even if previous strictness behavior is considered buggy, it's not clear that changing strictness behavior should be considered any less dangerous than consistent changes to type signature, e.g. generalizing them.)
The argument you're making is that API compatible changes are so much less disruptive that it's ok to have them more frequently.
I claim that's not really true. I claim that the synchronization is just as much about API additions as breakage. It's about stability. Users want to know which packages they should have to be able to run most Haskell code. Developers want to know what packages most users have got so they can make their code work with those versions. We can improve these periods of stability without reducing the pace of development by compressing changes into major releases rather than spreading them out.
Perhaps we should agree to disagree. Certainly additions can cause breakage (either by clashing with local definitions or by assuming they're exported), but I do think this breakage is sufficiently diminished that it's worth distinguishing it from the obvious breakage. That is, I think that many of the additions will not cause much breakage *in practice*, and so ---as per Claus' question of relevance--- allowing addition-releases between breakage-releases will serve to increase the duration of relevance and therefore overall stability. Whether this belief or your belief will be more correct depends, IMHO, on many factors that cannot be known without trying them. I, at least, do not think we have the information necessary to make *accurate* predictions about the stability/relevance of any particular approach. (Perhaps Don could provide an analysis of the frequency of API additions vs API breakages on Hackage?) I have a good deal of experience with F/OSS communities, but the pace of change in Haskell is far different than the pace in web development, applications, or OSes--- so I'm wary of how much experience from those areas can be effectively ported to this task. Another important issue that hasn't been much discussed is how long and to what extent do you plan to maintain old releases? I think the answer to this question will have major repercussions on both the frequency of non-bugfix releases and on whether it would be meaningful to distinguish enhancements from changes.
You bring up some good points about the pressure for maintainers to get new features into major releases. This is an important consideration in major release frequency. I suggest you take a look at Martin Michlmayr's PhD thesis in which he discusses this issue.
Quality Improvement in Volunteer Free and Open Source Software Projects: Exploring the Impact of Release Management http://www.cyrius.com/publications/michlmayr-phd.html
I have, it's a good read :) In Michlmayr's terms, I'm advocating for the notion of development releases for the HP as separate from development releases for the underlying projects on Hackage. Cutting edge vs bleeding edge, as it were. This is similar to GCC's three-tier model. Also it should make it easier to avoid OpenOffice.org's QA problems, while maintaining frequent (3~4 month) non-bugfix releases. -- Live well, ~wren