Platform policy question: API compatability in minor releases

[Duncan Coutts]

On Mon, 2009-05-11 at 18:31 -0400, wren ng thornton wrote:
> Duncan Coutts wrote:
> > On Sun, 2009-05-10 at 01:18 -0400, wren ng thornton wrote:
> > > I still think that it would be good to try to have a three stage model 
> > > for releases, instead of the two stage model that seems to be assumed. 
> > > Adding new packages or destructive API changes strike me as being very 
> > > different from compatible API changes (which are, in turn, separate from 
> > > big fixes and bundling fixes). I'd like to see these two types of 
> > > changes being distinguished in terms of the release schedule.
> > 
> > I have to say this isn't something I'd thought of. Tell us more. What
> > would this look like? Would it be something like eg only one release per
> > year is allowed to make breaking changes?
> 
> 
> As far as time frames, I think things will need adjusting as we find out 
> more about the development cycles of the new projects to be included in 
> the platform, but the idea is something in the spirit of my older 
> proposal, arguing "why choose":
> 
> On a long-term arc (e.g. 6~12 months) the HP would make major releases. 
> These releases could include new packages that have been blessed since 
> the previous major release, remove packages that have been deprecated 
> (heaven forfend), and destructive API changes as discussed in the PVP 
> (moving or renaming modules/functions, irreconcilable type signatures, 
> ADT changes,...).
> 
> On a mid-term arc (e.g. 3~4 months) the HP would make semi-major 
> releases. These releases could include compatible API changes as 
> discussed in PVP (adding new modules/functions, generalizing type 
> signatures (possibly),...). Potentially the addition of newly blessed 
> packages could move here, though see the discussion below.
> 
> On a short-term arc (e.g. 4~6 weeks) the HP would make minor releases. 
> These releases could include bug fixes for the underlying projects, 
> fixes to the packaging/cabalization of the projects, fixes to the 
> bundling of the HP, etc.


It's clear that bug fix only doesn't cause major compatibility headaches
(if done sanely) . It's obvious that API breakage causes upset.

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. 

Also consider Claus's question about how long a major release remains
relevant for. The more frequent our major releases (and that means new
features not just breakage) the more quickly they become obsolete.

I suggest we deal with the issue of users not wanting to upgrade too
frequently by having a major release cycle of a sensible length and
supporting old releases for a while.

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

Duncan