Platform policy question: API compatability in minor releases
wren ng thornton
wren at community.haskell.org
Thu May 14 23:09:36 EDT 2009
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
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
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.
More information about the Libraries