On Sep 14, 2009, at 2:47 PM, Joachim Breitner wrote:
Hi,I’m not the most experienced Haskell programmer, but that does not sound too involved to me. It sounds rather like a case of: For each additional argument (type or function), I obviously don’t need it, because my codeworks, so find out the proper default, add it, and when the code compiles again I’m done. It might be tedious (for all the type sigs), but not involved in the sense that it requires big, non-local code changes.
Yeah, it's mostly just tedious. There are two approaches Debian can take:
1. provide both APIs and compile each library/app against the API that it requires. Leave the choice of which API to use up to the upstream maintainers.
2. invest the man power to migrate all apps/libraries to the new API and then continue to maintain these modifications until the upstream maintainers decide to migrate as well.
Option 2 seems like more work (for Debian) than option 1, and I am not clear what benefits it brings besides having only one version of HaXml in Debian.
Additionally, as John Goerzen pointed out, many people use the HaXml package from Debian to build stuff that is not in Debian. As one of those people, I would greatly prefer to be able to apt-get install HaXml 1.13 and 1.20 at the same time so that I can migrate code on my own schedule, or, in some cases, not at all. So option 2 also seems like more work for Debian's users as well.
The 1.13.x series is stable, has been for years, and is not likely to require a lot of updates. The primary reason for using the newer versions of HaXml is if you want the new features it offers, not because it is less buggy. It is my belief that once a new stable version of HaXml comes out, people will be slow to migrate. It is very easy in cabal to just depend on < 14, and there is little motivation to upgrade. I think the demand for the newer version of HaXml will come from new apps or libraries that want to use the new features (such as it's SAX style parser).
- jeremy