package naming policy (was: Please check your dependencies on
dons at galois.com
Tue Jun 8 11:13:43 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-22.214.171.124) 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
> 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
Great points: I've added them to this wiki page of for and against
Please add points as you see fit, and maybe we can come up with a
More information about the Libraries