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

[John Lato]

On Tue, Jun 8, 2010 at 4:13 PM, Don Stewart <dons at galois.com> wrote:
> 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.
>

Thanks very much; that's a useful page.  It highlights some points I
hadn't considered, such as when the original author is no longer
involved with substantial changes to the code.

Hopefully a productive discussion will follow.  I don't think a
one-size-fits-all approach is appropriate, but it would be nice if the
community could come to some common recommendations on this topic.

Also, to everyone working on fgl: I certainly don't mean to single out
your work as an example, however I think your contributions to this
discussion are very helpful as it's a current issue for you.

John