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