Re: package naming policy (was: Please check your dependencies on fgl)
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.
On Tue, Jun 8, 2010 at 4:13 PM, Don Stewart
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.
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
jwlato:
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.
Yes, my intent here is to produce a set of guidelines for maintainers of important packages, that ensures we balance stability with innovation. We have a great document for what to consider when adding packages to the HP, for example: http://trac.haskell.org/haskell-platform/wiki/AddingPackages But nothing yet for maintainers who want to keep a package moving along.
On Tue, 8 Jun 2010, Don Stewart wrote:
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.
Closely related is the question of module names. 'transformers'+'monads-fd' are somehow an successor of 'mtl' and chose distinct package names, but there were module name clashes. They mostly hurted GHCi users, but this led to a lot of confusion, too. So the question is, if FGL gets a new name, should it also use different module names?
participants (3)
-
Don Stewart -
Henning Thielemann -
John Lato