2013/8/12 Jason Dagit
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.