Workflow for maintaining Haskell platform packages

Sven Panne svenpanne at
Mon Aug 12 09:35:36 CEST 2013

2013/8/12 Jason Dagit <dagitj at>:
> Good question. I tend to delay the version number bump in the .cabal
> file until I know how big it needs to be (according to the package
> version policy, or PVP). Then again, I'm fine with handling this in
> other ways.

Delaying the bump because of the PVP makes some sense, but IMHO it
makes local development a mess with several packages having the same
package number. Therefore I've bumped the version numbers on GitHub
already, incrementing the major number, because I now there will be
some non-backwards compatible changes.

As a side note, I am not totally sure why we constrain the package
versions via '==' in GLUT and GLURaw, but use '>=' in OpenGL. What's
the rationale behind this and what is the 'best' way?

> As for the releases, I've been creating tags for the commits that
> endup on hackage. For example, here is the tag for the
> release:
> The cool thing about using tags for this is that github knows how to
> treat them as releases:

I've seen that, and it seems to be a nice feature. I'm relatively new
to GitHub, so expect more dumb questions/proposals. ;-)

> I'm open to suggestions, so if branches would work better let me know.
> I think the current scheme still allows us to retroactively add
> release branches. So far, I've been resistant to backporting fixes to
> old releases simply because it seems like too much work relative to
> the benefit.

This is exactly my opinion, too, I was just concerned about how to
find out which git version ended up as which package version on

More information about the Libraries mailing list