[Fwd: Platform policy question: API compatability in minor releases]

[Duncan Coutts]

I sent this note to the libraries list to request a decision on a policy
decision: whether we should allow API additions in minor releases or
save API changes for major releases.

I would encourage you to express your opinion on the libraries list.

Duncan

-------- Forwarded Message --------
> From: Duncan Coutts <duncan.coutts at worc.ox.ac.uk>
> To: Haskell Libraries <libraries at haskell.org>
> Subject: Platform policy question: API compatability in minor releases
> Date: Sat, 09 May 2009 19:50:01 +0100
> 
> Hello everyone,
> 
> We (the platform release team) have a policy question about the Haskell
> Platform. We're asking here because we think the libraries list is the
> right authority to decide.
> 
> The Haskell Platform concept calls for major and minor releases. 
> 
>       * The point of major releases is to update the set of common
>         packages we all use. That is, to specify which packages and
>         which versions (corresponding to APIs). The target is to have
>         major releases every 6 months.
> 
>       * The point of minor releases is to support a major release across
>         a range of operating systems over time and respond to bugs that
>         are discovered in a library or tool subsequent to their release.
>         The target is to have 2-3 minor releases after major releases at
>         intervals on the order of 4-6 weeks.
> 
> The question is this:
> 
>         Should we allow compatible API additions to a library in a minor
>         release of the platform?
>         
>         The choice is between allowing only bug fixes in minor releases,
>         or also allowing new features that add APIs but do not change
>         any existing APIs.
> 
> It is clear that incompatible API changes must not be allowed in minor
> releases. On the other hand, bug fixes that do not change the API at all
> are ok.
> 
> Let me put some arguments in each case:
> 
> Allow compatible API additions
> 
>         If the change is compatible then it does not break any existing
>         programs, so it should be allowed. Any program that works with a
>         platform particular release will continue to work with
>         subsequent minor versions. This is standard backwards
>         compatibility policy.
>         
>         Getting minor feature improvements is sufficiently important
>         that it is too long to wait 6 months for the next major release
>         of the platform.
> 
> Allow only bug fixes, no API additions
> 
>         Forwards compatibility is important too. A developer should be
>         able to make a package and test it with platform version X.Y.2
>         and it should still work for a user with version X.Y.1. That way
>         we do not force upgrades on users all the time. Users should
>         only have to upgrade to a later minor release if earlier
>         versions didn't build/install/work on their OS, or if they hit
>         some particular bug which is fixed in a later minor release.
>         
>         There is no need for API changes in minor releases. Maintainers
>         can make a release with just the bug fixes to go into a minor
>         platform release and then make additional releases with new
>         features on Hackage. Users who want the new features can get the
>         new package version from Hackage.
>         
>         API additions in minor releases works against the distinction
>         between major and minor releases.
> 
> I hope that's not too biased a summary (I'll post my own opinion
> separately). If there is anything that I should clarify then please ask.
> 
> So please post your thoughts and arguments. I hope we can come to a
> conclusion within a few days. This is a timely issue because we aim to
> make a minor release on the 1st of June and we want to finalise the list
> of package versions two weeks prior, by the 18th of May.
> 
> http://trac.haskell.org/haskell-platform/wiki/ReleaseProcess
> 
> 
> Duncan
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries