Workflow for maintaining Haskell platform packages

[Sven Panne]

2013/8/12 Jason Dagit <dagitj at gmail.com>:
> 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 2.8.0.0
> release: https://github.com/haskell-opengl/OpenGL/tree/v2.8.0.0
>
> The cool thing about using tags for this is that github knows how to
> treat them as releases:
> https://github.com/haskell-opengl/OpenGL/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
Hackage.