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.