I'm not for a number of reasons:

- The libraries that come with GHC are huge and very few of them are completely stable. Even the H98 libraries change as H98 is refined.

- The statement that 'deprecated' means 'will not change until the next major release' isn't very satisfactory because:

1) People might disagree about what a major version is. The second sentence in this quote from SimonM suggests that the ':-)' is a typo and SimonM really doesn't regard 5.02->5.04 as a minor version change.

Ok, we define a major release to be anything that isn't a patchlevel release. They have been happenning at roughly 6-12 month intervals recently. The "major version number" (i.e the "5") doesn't correspond to a major release; we use it to indicate when the compiler gets a major overhaul or significant components are rewritten (so that you have a good idea when things might be unstable). eg. in 5.00 we introduced GHCi, in 4.00 we completely re-wrote the RTS, etc. It was debatable whether 5.04 should have been 6.00 since we introduced hierarchical libraries, but in the end we decided it didn't really constitute a significant rewrite, just a re-organisation of existing bits. 6.00 is on the horizon though: it will probably include Template Haskell, possibly Optimistic Evaluation, and a redesign of parts of the RTS and evaluation model that Simon & I are working on.

2) The timing of GHC releases is unlikely to be a useful measure to people relying on GHC in their project. Much more useful would be 'will not change before the POPL deadline' or 'will not change before our IPO'. That is, entities should be deprecated for a time period not a release cycle.

If you don't want things to change, don't upgrade! We're keeping releases stable for quite a long time these days: the 5.02 cycle lasted nearly 10 months, during which time we didn't break *anything* between releases. I wish we had the resources to maintain releases from two branches simultaneously, but sadly we don't.

To fix this situation (which I believe is common), we probably need something like:

1) Every entity in the API (type, function, module, etc.) should be assigned a 'stable period' such as 'stable until Jan 1st 2003'.

Do you know about the stability assignment for each module in the hierarchical libraries? Each module is classified as either 'stable', 'provisional', or 'experimental'. These terms are defined more precisely in http://www.haskell.org/~simonmar/libraries/libraries.html I think that's about the right level of rigour, given our current resources. The scheme you're proposing is, IMHO, unrealistic at the moment (although it may be the right thing in the future when things have settled down some more).

3) GHC's flag to warn about deprecated functions would take an optional expiry date as an argument. GHC would warn about use of entities which will expire before then. Probably on by default.

This is a good idea. Volunteers?

5) Each release would include a list of any entities removed ahead of schedule.

[It's open to debate whether this would do anything other than increase the motivation to keep the list small.]

I agree we ought to do a better job here. I'm sure there's a way to automate this at least partially: compare the library interfaces against the previous release's and document (or fix) any changes. Cheers, Simon