|
|
On Tue, Jun 8, 2010 at 4:13 PM, Don Stewart <dons@xxxxxxxxxx> wrote:
> jwlato:
>> > From: Don Stewart <dons@xxxxxxxxxx>
>> >
>> > 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@xxxxxxxxxxx
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|