Platform policy question: API compatability in minor releases

[Duncan Coutts]

On Sat, 2009-05-09 at 22:41 -0700, Bryan O'Sullivan wrote:
> On Sat, May 9, 2009 at 5:44 PM, Duncan Coutts
> <duncan.coutts at worc.ox.ac.uk> wrote:
>         
>         
>         I should probably point out the strategy we are trying to
>         implement:
>         time based releases rather than feature based.
> 
> And a fine idea that is. I do think that aiming for a 4-6 week minor
> release cycle is massive overkill, though. As a distro packager,
> there's no way I'm going to put myself through rebuild-the-world hell
> once a month because the core libraries keep getting tweaked, but then
> I run the risk of missing genuinely important bug or security fixes
> because I'm not paying attention. 

It's an interesting argument, that compared to C we have a problem with
upgrading too frequently because of no stable ABI etc. So on that basis
you argue that we should not have too many bug fix releases that people
are expected to upgrade to, but on the other hand we should have
reasonably frequent (3 month) major releases that people and distros are
expected to upgrade to.

It's a good point though I would resolve it differently. I would suggest
that we make it so that you don't actually have to upgrade to each minor
bug fix release if the first one you picked worked ok for you. Then we
only ask users and distros to upgrade (and thus rebuild everything)
every 6 months (or perhaps 4).

Note that distros do not package each minor release of GNOME (which come
out on a 4-6 week basis after each major 6-month release). Most wait for
x.y.2 or .3 before packaging them for a stable distro release. If we are
only including bug fixes and not new features then this would be doable
for the platform releases too.

> This "be careful with update frequency" problem is probably more acute
> for GHC than other languages because of the way that code tends to be
> inlined so aggressively.

True. This frequency of bug-fix releases only makes sense if people
don't have to upgrade to them unless they're hitting the specific bugs
that have been fixed. Just as now, people often don't bother to upgrade
to each new minor ghc release. For example, many distros never packaged
ghc-6.8.3, sticking to .2 and that was fine. Similarly, many have
skipped 6.10.2 (some even skipping 6.10.1).

> I'd aim for quarterly releases, with intermediate bugfix releases iff
> there's a genuine serious problem that needs fixing.

In the quarterly releases would you allow breaking API changes as well
as compatible API additions, or would you prefer something like only
breaking changes in alternate releases?

As I mentioned in my other note, I'd be happy enough with major releases
every 4 months rather than 6 with only bug fixes in between. My main
worry with more frequent releases is that we loose the synchronisation
effect.

Duncan