Daniel McAllansmith <dm.maillists at gmail.com> writes:
>>> I think what you're asking for is more than that: you want us to provide
>>> base-1.0, base-2.0 and base-3.0 at the same time, so that old packages
>>> continue to work without needing to be updated.
Yes.
>>> That is possible, but much more work for the maintainer.
How much more work, really? If the dependencies of your library have
similar backwards compatible support, you only have to keep track of
backwards-incompatible changes to the compiler, and I think those are
relatively few and far apart.
>>> Ultimately when things settle down it might make sense to do this
>>> kind of thing, but right now I think an easier approach is to just
>>> fix packages when dependencies change, and to identify sets of
>>> mutually-compatible packages (we've talked about doing this on
>>> Hackage before).
I'm surprised you think this is easier - There's an awful lot of
possible version combinations, and for every library that breaks,
there is - at least potentially - a lot of applications that needs
updating. Many of those will be web orphans that some curious newbie
will download and fail to get to work. (SOE, anybody? FiniteMap to
Data.Map?)
I think a library is more likely to be supported than an application,
and likely to be supported by more and more competent developers.
> I think it's a no-brainer that old versions of packages should remain
> available for people to use for 'a long time'. If their dependencies are
> specified properly they should continue building successfully as time passes.
Amen.
> Presumably it's not usually a problem if indirect package dependencies require
> incompatible versions of a package.
If it is, I think this is a strong argument in favor of "package
bundles" that are released and upgraded together as something
resembling a standard library.
-k
--
If I haven't seen further, it is by standing in the footprints of giants