Platform policy question: API compatability in minor releases

[wren ng thornton]

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