Re: Platform policy question: API compatability in minor releases

On Sat, 2009-05-09 at 22:41 -0700, Bryan O'Sullivan wrote:

On Sat, May 9, 2009 at 5:44 PM, Duncan Coutts 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