Platform policy question: API compatability in minor releases

[Duncan Coutts]

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