On Tue, Jun 8, 2010 at 4:13 PM, Don Stewart wrote:

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

Don Stewart writes:

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.

As part of this, we should consider if we want an official process to do what I've done to kick-off this whole discussion: have a way of telling users "Oj! New version coming up with heaps of changes!". Whilst major projects might have their own mailing lists, not all users might be subscribed to them, etc. Should we stick with what I've done and just email haskell@ and haskell-cafe@? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Jason Dagit writes:

On Tue, Jun 8, 2010 at 4:13 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

...

As part of this, we should consider if we want an official process to do what I've done to kick-off this whole discussion: have a way of telling users "Oj! New version coming up with heaps of changes!". Whilst major projects might have their own mailing lists, not all users might be subscribed to them, etc.

Should we stick with what I've done and just email haskell@ and haskell-cafe@?

Yes, and posting to reddit and having an article on planet haskell about it helps too. There are lots of ways to get the same information and using more of them will help you reach your audience.

Well, someone else would have to do the posting on reddit for me; I waste too much time as-is reading it let alone posting there and getting involved in the discussions on yet another front! ;-) I'll do up a blog post in the next day or so to get it on planet though. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Henning Thielemann writes:

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?

This has been brought up already. My intention is, before we release it publically/visibly, we get in contact with all package maintainers of hackage packages that use FGL and help them migrate to the new version so we can do a mass migrate/upgrade so that there would be no reason for users to have the old version of FGL installed (unless there's a system package vs cabal-install package clash, but there's not much we can do about that). The unfortunate aspect of this IMHO is that the FGL package name doesn't match the module names; if it was the consensus of the community that we change the package name of FGL one option I was thinking of was something along the lines of "inductive-graphs", but the obvious choice of module names for that would be Data.Graph.Inductive, which FGL has already taken. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com