On Sun, 2009-05-10 at 12:05 +0200, Sven Panne wrote:
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?
We can make the numbering consistent with whichever policy we choose.
* 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*.
GNOME releases have two target audiences. One group, as you say, are end users who just want a working desktop and don't mind too much if there are extra features so long as existing stuff doesn't break. However a major plank of the GNOME release is the "GNOME developer platform" which really is just a set of libraries for making desktop applications. Many third parties rely on these libraries and the API guarantees. It is this second aspect that is relevant to us.
* 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!
Yes, it's about packaging. Packaging people are intermediaries between maintainers and users and they have to respond to the needs of both. Of course they cannot force anyone to do anything.
* 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.
Sure. But of course there is no problem with making releases on hackage and users who need OpenGL 3.1 in the few months between major HP releases could use cabal to get the latest from Hackage. The question is how often we ask all end users and distributors to update everything? For an active package the maintainer might like to put out a release every week and some subset of users will be quite happy to grab that. But how often do they want to update everything else? I bet it is more on the order of 4-6 months (and some users will prefer longer and skip updates). The platform is certainly not about arresting progress and development. It's about helping end users and developers to manage change by compressing changes into regular, well defined points -- major releases -- and in between providing a little consistency and stability. Duncan