Rewriting a famous library and using the same name: pros and cons

[Jeremy Shaw]

I don't really see this listed on your list, but maybe I missed it.

Happstack has been affected by QuickCheck 1 -> QuickCheck 2, parsec 2
-> 3, and HaXml 1.13 -> 1.20.

Those packages are common, and people often want to use happstack with
other libraries that also use those packages. The problem is that if
we upgrade to the newer versions, then people can't use happstack with
libraries that use the old version. For example, when we upgrade to
QuickCheck 2, gitit no longer installed, because some dependency of
gitit still used (and perhap still does) QuickCheck 1.

We are now faced with the same problem with HaXml. Do we upgrade to
1.20 and stick with 1.13 for a while? Either way we cause
incompatibilities.

The the cause of QuickCheck, 99% of the time, it would have been ok to
link the app against QC1 and QC2, because no one ever tried to combine
the QC1 tests and the QC2 tests. So, in that cause, making QC1 and QC2
completely different packages would have solved our problem. Duncan C,
also proposed a system whereby we could declare QuickCheck as an
'internal' dependency -- meaning we never export any QC2 functions or
types to the outside word, so it is safe to link against other
versions of QC. That would have worked fine as well, but the proposal
does not seem to have gotten any traction yet. That is unfortunate,
because it seems useful.

In the case of HaXml, things are a bit trickier. It is more likely
that people are going to want to use the HaXml stuff we export with
other libraries that use HaXml, so everyone would have to be using the
same version of HaXml then. At the same time, not very many people
actually use the HaXml stuff in happstack, even if they are using
another library that use HaXml. So, for most people the version
mismatch isn't really an issue. So, like QC, it would actually
probably be better for use if HaXml 1.13 and 1.20 had unique package
names, so we could link against multiple HaXml versions.

Of course, in the case of QC2 and HaXml, the ultimate solution is that
everyone upgrades to the latest, and then the problem goes away. But,
once you start depending on a larger number of packages directly and
indirectly, it does not take very long before you run into someone
that has not updated to the latest, and then you are kind of stuck...

As a maintainer, I have no idea when the right time to switch to HaXml
1.20 is.. and that is an issue. That same would be true of fgl
(though, fortunately, happstack doesn't use that yet). The only
solution I have at the moment, is to upgrade to HaXml 1.20, and then
send patches to any other direct or indirect dependencies of happstack
that use HaXml and get them upgraded as well.. Maybe that is the best
solution.. though it is also a lot of work.

- jeremy

On Tue, Jun 8, 2010 at 10:08 AM, Don Stewart <dons at galois.com> wrote:
>
> There have been a few cases of major API  / rewrites to famous old
> packages causing problems, including:
>
>    * QuickCheck 1 vs 2
>    * parsec 2 vs 3
>    * OpenGL
>
> a similar opportunity is present with 'fgl', where the new maintainers
> are seeking to improve the code.
>
> Below I try to summarise the pros and cons of calling the new
> rewrite/api 'fgl', in the hope we can identify a path that minimizes
> disruption to users.
>
> ------------------------------------------------------------------------
>
>
> A group of developers is planning to write a new graph library for
> Haskell.
>
>    * They maintain an existing package called 'fgl'.
>    * 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/
>    * The new library will have different authors and a different API.
>    * They would like the new library 'fgl'.
>
> It is a controversial step to write a new library and give it the same
> name as an existing, famous library. Let's look at the arguments.
>
> = Reasons to use the new name =
>
>  * The new code  will be better, and should be preferred. Using the name
>   'fgl' will ensure adoption.
>
>  * Rewrites are effective if the name is preserved. E.g. QuickCheck 2.
>
>  * It is the maintainer's right to modify APIs as they see fit.
>
>  * Keeping the old fgl around as a separate package, there is then
>        no real incentive to change/upgrade.
>
>  * Relatively few packages use fgl. So damage is limited.
>
> = Reasons not to use the name =
>
>  * Code that depends on 'fgl' will break.
>       There are 23 direct and 25 indirect dependencies on fgl.
>       http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct
>
>  * Doesn't matter if the old fgl is still around. If the new code is
>   better, it will be adopted on its own merits (see e.g.
>   bytestrings vs packedstring, vector vs uvector)
>   Let the market decide if it is better, rather than forcing us.
>
>  * The package has been stable for ~10 years -- why change a stable API?
>    It is already "perfect"
>
>  * The new package really isn't the same package in any sense.
>
>  * Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)
>
>  * No additional breakages are introduced.
>
>  * If you weren't maintainer of 'fgl' this rewrite wouldn't even be
>   possible to call 'fgl' -- there's a conflict of interest.
>
>  * Maintaining Haskell98 compatability. Keep it simple. (See
>   regex-posix's mistakes here)
>
>  * Distros that support the Haskell Platform will have to keep an old
>   version of fgl around for a long time anyway.
>
>
> Are there any other arguments I'm missing?
>
> -- Don
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>