jwlato:
From: Don Stewart
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.
Great points: I've added them to this wiki page of for and against points: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename Please add points as you see fit, and maybe we can come up with a mitigation/change plan.