[Haskell-cafe] naming and packaging things

[Rico Moorman]

Hi everyone,

As anyone following this mailinglist surely noticed, there are a few
issues regarding haskell packaging.

Lot of discussion is going on about how cabal contributes to the
problems and how things could be fixed by making our tools smarter (which
is a great thing to do IMHO).

I think though, that there might be other ways to deal with or at
least reduce the problems.

One of those ways would be expressing the influence of changes in
a package's public API, using the name of a package instead of just
version numbers.

I mean, in case a major backwards incompatible/breaking change happens,
one would change the name of the package/namespaces a.s.o. And with
breaking I really mean that kind of "oh my ... now I have to rewrite this
part of my application because of this". Simple additions to the API do not
count as breaking because existing functionality is left alone.

This way, incompatible versions of the "same" library can coexist
without any problems right within the same program if one chose to do so
even allowing for improved transition processes for larger application
I presume.  It would easily be possible to safely install newer versions
of the same package without breaking things.

There are more open source libraries/projects as it seems, which use
this approach (version number in the package name) such as the kdelibs,
gtk, beautifulsoup, apache and bind.

One example: take an application which needs two libraries A and B
which both depend on library C. Now lets assume that A uses a slightly
older version of C and B uses a version with a major incompatibility. In
the current versioning scheme, there could be major problems
causing development delays or custom forks to emerge a.s.o.
But following the other naming method, in case library C chooses
to introduce a major breaking change in the public API, a new package C2
is born, which can be used alongside C (and effectively is a different
library anyway I think).
The choice for the new version of C (C2) is explicit within the name
and all related things.

I am aware of the fact that this would take more forethought on
library design, but I do not think that this alone would be a bad idea
anyway.
Also it would be difficult to enforce this, but well, a good
maintainer would be aware of this anyway, taking care of not introducing
breaking changes to the public API I guess.

Furthermore we would end up with more packages with different names
(but probably the same idea behind it) which would be on hackage. Likely
it would be nice to add some grouping or tagging features which would
bind them together for everyone browsing the packages. But I think this
is probably not a real problem but more a cosmetic one.

I really would like to see this discussed here. What would be the good
and the bad of promoting this kind of versioning?

I am looking forward to hear what you think.

Best regards,

Rico Moorman


P.S. sorry if you got this twice but I seem to have mail problems at the
moment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121122/42fb471d/attachment.htm>