Workflow for maintaining Haskell platform packages

[Jason Dagit]

On Sun, Aug 4, 2013 at 9:32 AM, Sven Panne <svenpanne at gmail.com> wrote:
> 2013/8/4 Jason Dagit <dagitj at gmail.com>:
>> 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