Workflow for maintaining Haskell platform packages
svenpanne at gmail.com
Mon Aug 12 09:35:36 CEST 2013
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 220.127.116.11
> release: https://github.com/haskell-opengl/OpenGL/tree/v18.104.22.168
> 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