Well, I dislike epochs, since we can never get rid of them.It is my feeling that we are going to need to provide both HaXml 1.13 and 1.20 because many library authors won't bother to upgrade something that has been working fine for the last 4 years. Last time I checked, the migration was somewhat involved. The types and constructors have an additional argument, so pretty much every type signature needs to be updated, and other functions need extra arguments. I expect that none, or almost no code will compile as-is with 1.20.
If that is true, then I would be happy with leaving the current HaXml upload alone and creating libghc6-haxml13-dev and having packages depend on that if they want the old API.
Upsides: - probably have to do it eventually anyway - avoids adding an epoch for the rest of time Downside:- requires significantly more work now. (Though, we make up for it in the long run?)
- jeremy On Sep 11, 2009, at 5:15 PM, Joachim Breitner wrote:
Hi, Am Freitag, den 11.09.2009, 15:05 +0100 schrieb Iain Lane:So I would recommend that we roll back until the new series is declared stable and rdepends start migrating to the new API. I also hope that upstream can make this situation more manifest on their hackage page - having `cabal install haxml' install an unstable version is surely an undesirable situation.so would everyone be happy with this solution? Then we can do an haxml-1.13 upload with bumped epoch and leave it like this for now. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata