Platform policy question: API compatability in minor releases

[Sven Panne]

Am Samstag, 9. Mai 2009 20:50:01 schrieb Duncan Coutts:
> [...] 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.
> [...]

We should definitely allow API additions in minor platform releases. Most 
arguments for this have already been written, but I'd like to point out a few 
ones:

   * Consistency in numbering: The platform numbering should have the 
semantics as the numbering of its parts, therefore allowing API additions in 
minor releases. If someone is totally unwilling to risk any changes his code, 
he can still use bug fix releases of the platform instead of minor releases, 
where's the problem?

   * IMHO, GNOME is a not a good example, although it is cited here over and 
over again. GNOME is mainly supposed to be used by *end users*, while the 
Haskell platform is supposed to be used by *programmers*. Both target groups 
have very different needs. As a desktop user I probably don't care much about 
some feature additions, as long as my good old working environment stays the 
same. As a programmer I'd like to get bug fixes very quickly, get early 
indications of the direction where a library evolving, try out new cool 
features, etc. There is always a tension between stability and new features, 
but given *our* target group, let's not focus on the wrong thing too heavily.

   * A crucial point in most open source SW development is the distinction 
between the maintainer of a piece of SW and a packager (nomenclature my vary, 
but you get the point). The Haskell platform is all about packaging, nothing 
else. Trying to force the maintainers to handle bug fix branches just for the 
platform's sake is a no-go IMHO, and something I personally won't do for my 
libraries. Let's keep the maintainer-packager distinction as it is!

   * Let's assume that the Haskell platform keeps its planned interval of 6 
months for major releases (something I am not totally convinced of until it 
has happened reliably a few times). If we allowed API additions only twice a 
year, this would be ridiculously slow, because the world outside doesn't stand 
still. The OpenGL ARB e.g. released their OpenGL 3.1 spec only 9 months after 
the OpenGL 3.0 spec, and the differences were by no means small. You can't 
compare e.g. the network package with this, because improvements or additions 
in network APIs are virtually non-existent compared to this, we basically 
still use APIs which are a few decades old. Consequently, allowing API 
additions only every 6 months would be more than enough for the network 
package, but it would be far too slow for the OpenGL package.

Cheers,
   S.