jwlato: > > From: Don Stewart <d...@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.
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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe