[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121121/dc6a82bd/attachment.htm>