Re: Workflow for maintaining Haskell platform packages

On Sun, Aug 4, 2013 at 9:32 AM, Sven Panne wrote:

2013/8/4 Jason Dagit :

...

I'm not sure if I've understood you correctly, but if the problem is how to have both installed then the answer is cabal-dev or hsenv. Oh, and the unreleased version of cabal (on github) has built in sandboxing.

Yes, that exactly is the problem. I'll try cabal-env/hsenv then.

One more workflow question: Wouldn't it make sense to make a branch on GitHub for each released version of a package and bump the package version on master directly after that? I know that there are tons of ways working with git, but I think that this one is quite common and makes a lot of sense to me.

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. 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'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. Jason