Multi-versioning and compatibility classes.

[Jason Dusek]

  I have been looking at the Cabal roadmap (tickets marked for
  bottom) and notice that no one has mentioned multi-versioning
  or compatibility classes. Maybe these are bad ideas?

  Multi-versioning seems highly desirable. Essentially, it
  allows us to have the same qualified names be provided by
  different packages for different packages. This is desirable
  in the case of package versions which really are no longer the
  same, like Parsec 2 and Parsec 3; it also allows for the case
  where more than one package specifies the same qualified name
  because it is obvious (like `Text.JSON` or some such). It
  stands to reason that the "package environment" specified in
  the `.cabal` file is enough to tell us which package we really
  need to use.

  However, there are problems, too. Like what if I have one
  package that depends on `parsec-2.1.0.1` and another that
  depends on `parsec-2.1.0.0`? With multi-versioning, they both
  compile fine but then I try to use a parser from one with a
  combinator defined in the other: this fails to compile
  because:

    parsec-2.1.0.1:Text.ParserCombinators.Parsec.GenParser

  is not the same as:

    parsec-2.1.0.0:Text.ParserCombinators.Parsec.GenParser

  So now we need compatibility classes. The first package might
  specify a package dependency like:

    ~parsec-2.1.0.1

  where we take the `~` to mean "requires something compatible
  with". The second package specifies a similar dependency:

    ~parsec-2.1.0.0

  Then the maintainer of Parsec specifies that 2.1.0.1 is
  compatible with 2.1.0.0 and we can compile the second package,
  the one that require 2.1.0.0, with 2.1.0.1 since they are
  compatible and that is all it is asking for. Then we try to
  use these two packages together and everything works.

--
Jason Dusek