Platform policy question: API compatability in minor releases

[Duncan Coutts]

Hi Claus,

I've been trying (unsuccessfully) to avoid replying to every single
message in this thread, however you raise a number of interesting things
that we've not asked ourselves yet in this discussion.

On Sun, 2009-05-10 at 23:00 +0100, Claus Reinke wrote:
> I suspect this is too simple a picture of what people expect from the HP!-)
> Some examples:

You're right. We started with much too narrow a question that was laden
with too many assumptions. It's right to look at the bigger picture (so
long as it helps us come to some sort of conclusion! :-) )

> - stability: used to be about language stability alone, but these days,
>     libraries are a big part of the game, language standards are a bit slow
>     in keeping up with language extensions, and GHC releases no longer
>     come with a "standard" kitchensink of extensions and libraries
> 
>     Here, the question is: can I write code/documentation wrt HP x.y.z,
>     and will the combination remain accessible, useable, and relevant?
>     And which stability problems does the HP not address/solve?

'relevant' is a particularly good word in this context. What does it
mean for a release to remain relevant?

I'd say that a release becomes *irrelevant* shortly after developers
stop testing their packages against that releases.

Given that we cannot expect developers to test against more than two or
three releases then irrelevance is directly related to the frequency of
releases. If we have bi-annual releases then a user could expect to
stick with a single release for 12-18 months. On the other hand if we do
quarterly releases then the time to irrelevance is significantly
reduced.

Duncan