[Haskell-cafe] ANN: HDBC v2.0 now available

[John Goerzen]

Duncan Coutts wrote:
> On Sun, 2009-02-01 at 15:56 +0100, Niklas Broberg wrote:
>>> So in the next cabal-install release (which should be pretty soon now)
>>> configure will do the same thing and pick base 3 unless you specify
>>> build-depends base >= 4.
>> ... and so there will never be any incentive for these many packages
>> to migrate to base-4, which also has consequences for packages that do
>> want to use base-4, but also want to depend on such packages.
> 
> Actually a package that uses base 4 can depend on other packages that
> use base 3. They all co-exist fine. This already happens now.
> 
>> I would suggest as a less stagnating approach to issue a warning/hint
>> when a package with no explicit version dependency for base fails to
>> build.
> 
> So my plan is to make hackage require an upper bound on the version of
> base for all new packages. That should avoid the need to use the
> preferences hack the next time around.

Hrm.  I can see why you might do that, if you keep the old base around.

On the other hand, what if base 5 introduces less invasive changes?

We have had, for awhile, a number of Haskell packages in Debian that
require a version of GHC greater than version x and less than version
x+1.  This has not worked out entirely well for us.  Granted, Cabal is
different because GHC 6.10 has two versions of base.

But still, I feel queasy about stating that my package won't work with
base 5 when I haven't even seen base 5 yet.

While we're at it, isn't this a more general problem that could occur
elsewhere?  Does base really need to be a special case?  What if, say,
utf8-string, binary, or some other commonly-used package had to break API?

> As for what mechanisms we use to persuade package authors to use base 4
> over base 3 for new releases, I'm open to suggestions.

Well, I'd say this will be difficult to achieve for at least two years,
since GHC 6.8 is in current and future shipping versions of numerous
Linux distributions, and such may well be the version of GHC most
readily accessible to quite a few users.

I am taking the approach of supporting *both*, but that is certainly not
the most simple approach (it's not all that complex either, once you
know how).

-- John