Personal tools

Libraries/WhenToRewriteOrRename

From HaskellWiki

< Libraries(Difference between revisions)
Jump to: navigation, search
 
Line 2: Line 2:
 
packages causing problems, including:
 
packages causing problems, including:
   
* QuickCheck 1 vs 2
+
* QuickCheck 1 vs 2
* parsec 2 vs 3
+
* parsec 2 vs 3
* OpenGL
+
* OpenGL
   
 
a similar opportunity is present with 'fgl', where the new maintainers
 
a similar opportunity is present with 'fgl', where the new maintainers
Line 14: Line 14:
   
 
------------------------------------------------------------------------
 
------------------------------------------------------------------------
 
   
 
A group of developers is planning to write a new graph library for
 
A group of developers is planning to write a new graph library for
 
Haskell.
 
Haskell.
   
* They maintain an existing package called 'fgl'.
+
* They maintain an existing package called 'fgl'.
* 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/
+
* 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/
* The new library will have different authors and a different API.
+
* The new library will have different authors and a different API.
* They would like the new library 'fgl'.
+
* They would like the new library 'fgl'.
   
 
It is a controversial step to write a new library and give it the same
 
It is a controversial step to write a new library and give it the same
Line 29: Line 28:
 
= Reasons to use the new name =
 
= Reasons to use the new name =
   
* The new code will be better, and should be preferred. Using the name
+
* The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption.
'fgl' will ensure adoption.
 
   
* Rewrites are effective if the name is preserved. E.g. QuickCheck 2.
+
* Rewrites are effective if the name is preserved. E.g. QuickCheck 2.
   
* It is the maintainer's right to modify APIs as they see fit.
+
* It is the maintainer's right to modify APIs as they see fit.
   
* Keeping the old fgl around as a separate package, there is then
+
* Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade.
   
no real incentive to change/upgrade.
+
* Relatively few packages use fgl. So damage is limited.
   
* Relatively few packages use fgl. So damage is limited.
+
* It makes development by new users simpler by not fracturing the
  +
package-space (the "Which version of QuickCheck should I use?"
  +
problem).
  +
  +
* It decreases the maintainer workload as the same person or team will
  +
often be responsible for both packages.
   
 
= Reasons not to use the name =
 
= Reasons not to use the name =
   
* Code that depends on 'fgl' will break.
+
* Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct
There are 23 direct and 25 indirect dependencies on fgl.
 
http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct
 
   
* Doesn't matter if the old fgl is still around. If the new code is
+
* Doesn't matter if the old fgl is still around. If the new code is
better, it will be adopted on its own merits (see e.g.
+
better, it will be adopted on its own merits (see e.g.
bytestrings vs packedstring, vector vs uvector)
+
bytestrings vs packedstring, vector vs uvector)
Let the market decide if it is better, rather than forcing us.
+
Let the market decide if it is better, rather than forcing us.
   
* The package has been stable for ~10 years -- why change a stable API?
+
* The package has been stable for ~10 years -- why change a stable API? It is already "perfect"
It is already "perfect"
 
 
 
* The new package really isn't the same package in any sense.
+
* The new package really isn't the same package in any sense.
   
* Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)
+
* Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)
   
* No additional breakages are introduced.
+
* No additional breakages are introduced.
   
* If you weren't maintainer of 'fgl' this rewrite wouldn't even be
+
* If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest.
possible to call 'fgl' -- there's a conflict of interest.
 
   
* Maintaining Haskell98 compatability. Keep it simple. (See
+
* Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here)
regex-posix's mistakes here)
+
+
* Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway.
* Distros that support the Haskell Platform will have to keep an old
 
version of fgl around for a long time anyway.
 

Revision as of 14:08, 8 June 2010

There have been a few cases of major API / rewrites to famous old packages causing problems, including:

  • QuickCheck 1 vs 2
  • parsec 2 vs 3
  • OpenGL

a similar opportunity is present with 'fgl', where the new maintainers are seeking to improve the code.

Below I try to summarise the pros and cons of calling the new rewrite/api 'fgl', in the hope we can identify a path that minimizes disruption to users.


A group of developers is planning to write a new graph library for Haskell.

  • They maintain an existing package called 'fgl'.
  • 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/
  • The new library will have different authors and a different API.
  • They would like the new library 'fgl'.

It is a controversial step to write a new library and give it the same name as an existing, famous library. Let's look at the arguments.

1 Reasons to use the new name

  • The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption.
  • Rewrites are effective if the name is preserved. E.g. QuickCheck 2.
  • It is the maintainer's right to modify APIs as they see fit.
  • Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade.
  • Relatively few packages use fgl. So damage is limited.
  • It makes development by new users simpler by not fracturing the

package-space (the "Which version of QuickCheck should I use?" problem).

  • It decreases the maintainer workload as the same person or team will

often be responsible for both packages.

2 Reasons not to use the name

  • Doesn't matter if the old fgl is still around. If the new code is

better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us.

  • The package has been stable for ~10 years -- why change a stable API? It is already "perfect"
  • The new package really isn't the same package in any sense.
  • Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)
  • No additional breakages are introduced.
  • If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest.
  • Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here)
  • Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway.