Sven Panne | 4 Aug 16:33 2013
Picon

Workflow for maintaining Haskell platform packages

Currently I'm trying to pick up my work on the OpenGL-related packages
again, and while doing that, I came across some organizational
difficulties: The GLUT/OpenGL/OpenGLRaw/GLURaw packages are now part
of the Haskell platform (thanks to Jason and others, this is really
great!), and they depend on each other, e.g. GLUT => OpenGL =>
OpenGLRaw.

So my question is: What is the recommended workflow to easily
maintain/extend packages contained in the Haskell platform? I want to
be able to quickly go back to the distributed package versions, OTOH I
want to relatively quickly try out new things, extend APIs, etc. for
the upcoming new versions of those packages. Any hints how to do that
are highly appreciated.

Cheers,
   S.
Jason Dagit | 4 Aug 18:13 2013
Picon

Re: Workflow for maintaining Haskell platform packages

On Sun, Aug 4, 2013 at 7:33 AM, Sven Panne <svenpanne <at> gmail.com> wrote:
> Currently I'm trying to pick up my work on the OpenGL-related packages
> again, and while doing that, I came across some organizational
> difficulties: The GLUT/OpenGL/OpenGLRaw/GLURaw packages are now part
> of the Haskell platform (thanks to Jason and others, this is really
> great!), and they depend on each other, e.g. GLUT => OpenGL =>
> OpenGLRaw.
>
> So my question is: What is the recommended workflow to easily
> maintain/extend packages contained in the Haskell platform? I want to
> be able to quickly go back to the distributed package versions, OTOH I
> want to relatively quickly try out new things, extend APIs, etc. for
> the upcoming new versions of those packages. Any hints how to do that
> are highly appreciated.

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.

I hope that helps,
Jason
Sven Panne | 4 Aug 18:32 2013
Picon

Re: Workflow for maintaining Haskell platform packages

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.

Thanks for the hints,
   S.
Henning Thielemann | 4 Aug 18:38 2013
Picon

Re: Workflow for maintaining Haskell platform packages


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.
Sven Panne | 5 Aug 13:51 2013
Picon

Re: Workflow for maintaining Haskell platform packages

2013/8/4 Sven Panne <svenpanne <at> gmail.com>:
> 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.

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?
Jason Dagit | 12 Aug 06:51 2013
Picon

Re: Workflow for maintaining Haskell platform packages

On Mon, Aug 5, 2013 at 4:51 AM, Sven Panne <svenpanne <at> gmail.com> wrote:
> 2013/8/4 Sven Panne <svenpanne <at> gmail.com>:
>> 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.
>
> 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
Sven Panne | 12 Aug 09:38 2013
Picon

Re: Workflow for maintaining Haskell platform packages

2013/8/12 Jason Dagit <dagitj <at> gmail.com>:
> cabal-dev and the (unreleased) sandbox support in cabal both work well
> on windows. I've used both of them on windows :)

I'll probably take a look at them later. I've just found out that the
low-tech solution of configuring/installing the packages via --user is
enough for my purposes for now (the user packages shadow the global HP
ones). Let's see when the pain gets big enough to switch to a more
sophisticated solution. :-)
Jason Dagit | 12 Aug 06:57 2013
Picon

Re: Workflow for maintaining Haskell platform packages

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
(Continue reading)

Sven Panne | 12 Aug 09:35 2013
Picon

Re: Workflow for maintaining Haskell platform packages

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 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
(Continue reading)

Henning Thielemann | 12 Aug 09:49 2013
Picon

Re: Workflow for maintaining Haskell platform packages

Am 12.08.2013 09:35, schrieb Sven Panne:
> 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.

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.

Gmane