package naming policy (was: Please check your dependencies on fgl)

[Don Stewart]

jwlato:
> > 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.

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.