[Haskell-cafe] Re: package naming policy (was: Please check your
dependencies on fgl)
John Lato
jwlato at gmail.com
Tue Jun 8 10:52:28 EDT 2010
> From: Don Stewart <dons at galois.com>
>
> ivan.miljenovic:
>> Thomas Bereknyei are currently re-writing fgl (just about completely
>> from scratch) and we plan to make an initial release to get feedback
>> on the API in the next few weeks.
>>
>> However, I'm sending this email out now to warn people that I highly
>> doubt any code that was written for the current version of fgl
>> (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the
>> new version.
>
> How about you give the library a different name then -- so as not to
> break all those programs?
>
> A complete rewrite with a new maintainer: fgl-awesome
I would like to argue against this practice, i.e. re-naming new,
incompatible versions of existing packages. I think it's bad for the
following reasons:
1. It makes development by new users more difficult by fracturing the
package-space (the "Which version of QuickCheck should I use?"
problem). Since this is already an acknowledged issue, I think it's
better that developers not add to it.
2. It discourages adoption of the latest version despite any benefits
the later version may provide. This also leads to greater
incompatibility between dependent packages.
3. For packages in the platform, I believe this will create
uncertainty about which package(s) should be included with new major
releases.
4. It adds to the maintainer workload as the same person or team will
often be responsible for both packages.
I do agree that there are legitimate reasons why users may decide to
remain with older versions, however I think that in nearly all cases
the proper solution is to follow the PVP and for users to include
upper dependency bounds in .cabal files. In particular, for the very
common case of compatibility with older code, an upper dependency
bound seems like the correct approach.
IMHO changing a package name should be for when developers intend to
continue development (not just maintenance releases) along both
branches.
My 2 cents, anyway.
John
More information about the Haskell-Cafe
mailing list