Christian Maeder <christian.mae...@dfki.de> writes: > Ivan Lazar Miljenovic schrieb: >> We considered giving it a new name (fgl', etc.) but figured that in the >> long term this wouldn't be advantagous. We feel that the situation is >> analogous to QuickCheck: when the new version came out most people kept >> using the old one until slowly the momentum shifted and more people >> started using the new version (without checking in depth, Roel's Hackage >> mirror reports QC-2.x now has 153 reverse dependencies as opposed to 127 >> reverse dependencies for QC-1.y). >> >> If we changed the name, then the "emotional attachment" that the Haskell >> community has to FGL being the de-facto graph library means that people >> would keep using the old version. Whilst we also face the possible >> problems of people not liking the old version and thus automatically >> dismissing the new version, I think this is a much more unlikely >> scenario. > > I'm afraid you'll destroy the "emotational attachment" to fgl by > annoying incompatibilities (and possibly interfering new bugs). > > Although parsec-3 can be used as an replacement for parsec-2 it would > have been better, they had different names (as argued elsewhere for the > haskell platform).
I'm sorry, I don't recall this discussion: care to summarise? With fgl, the actual changes aren't that big on the user side of things if they want to keep using the defaults (it's not a drop-in replacement, but the _way_ to use it remains unchanged). The big difference is when people want to make custom instances; however, as far as I know no-one has created any custom instances for FGL's classes. > Changing a dependency in a cabal file is a small problem. > Those (unaware), who only mention "fgl", will fall over an > incompatibility (usually at installation time!) and simple say "fgl < > ..." unless they are willing to change their code then. > > Those who already have "fgl < ..." need to find an advertisement of a > "new and better fgl" anyway and can choose when to change their code. But by keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. If, however, we re-use the package name then it will be more obvious that there is a new and (hopefully) improved version available. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell