On Sun, 4 Aug 2013, Sven Panne wrote:

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 think bumping the version in the repository right after a Hackage upload is the right thing to do. This way users can install the repository HEAD version with cabal-install. Only this way a GL-using package can specify that it depends on a GL package version that is not yet present on Hackage.

On Mon, Aug 5, 2013 at 4:51 AM, Sven Panne wrote:

2013/8/4 Sven Panne :

...

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.

Hmmm, https://github.com/Paczesiowa/hsenv says that hsenv doesn't work on Windows, so this is not an option for me, because I want to develop and Linux *and* Windows. Before I'll start wasting my time: Does cabal-env work on Windows?

cabal-dev and the (unreleased) sandbox support in cabal both work well on windows. I've used both of them on windows :) Jason

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

Am 12.08.2013 09:35, schrieb Sven Panne:

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.

I usually increment the version number directly after a Hackage upload by a minimal version increment, e.g. 0.0.0.0 -> 0.0.0.1. If I make bigger changes later, I increment the version again as much as necessary to meet the PVP.