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

[Duncan Coutts]

On Sun, 2009-02-01 at 13:58 -0600, John Goerzen wrote:

> > 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?

Then it would not be base 5, it would be 4.something. That's the point
of the versioning policy.

http://haskell.org/haskellwiki/Package_versioning_policy

> 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.

But it's easy to change it when you do see base 5 but it's annoying for
everyone when it fails messily. If you take the conservative approach
it's clear to end users and everyone else. We can track the status much
more easily.

> 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?

That is what the package versioning policy is for. Any package can
opt-in to following it. In which case other packages that depend on said
package can rely on it and use appropriate version constraints.

All the core and platform packages follow the versioning policy.

The plan is to add tool support to let packages declare that they follow
the policy (eg: version-policy: PVP-1) and then we can check that the
package really is following the policy and we can also make helpful
suggestions to other packages that depend on it (ie tell them what
version constraints to use).

http://hackage.haskell.org/trac/hackage/ticket/434#comment:1

> > 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.

However I'm not sure that it will be possible for ghc-6.12 to support
base 3 4 and 5. Some kinds of changes (especially to types) make
supporting multiple versions impossible.

> 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).

I'm not advocating dropping support for base 3. So I guess I am
advocating supporting both. I'm also not sure we need everyone to switch
now, but it'll become more important when we get nearer to ghc-6.12 next
autumn.

Duncan