Hi Bryan,
On Mon, Aug 27, 2012 at 7:27 AM, Bryan O'Sullivan b...@serpentine.com wrote:
[...]
Does this sound reasonable?
+1 from me.
One question: why freeze both master and stable instead of only stable?
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against
On Mon, Aug 27, 2012 at 8:30 AM, Mikhail Glushenkov
the.dead.shall.r...@gmail.com wrote:
One question: why freeze both master and stable instead of only stable?
I should have been clearer, sorry. At release, stable starts tracking what
was the master branch. It doesn't freeze as such
Hi,
On Mon, Aug 27, 2012 at 6:08 PM, Bryan O'Sullivan b...@serpentine.com wrote:
On Mon, Aug 27, 2012 at 8:30 AM, Mikhail Glushenkov
the.dead.shall.r...@gmail.com wrote:
One question: why freeze both master and stable instead of only stable?
I should have been clearer, sorry. At release,
On Mon, Aug 27, 2012 at 10:35 AM, Mikhail Glushenkov
the.dead.shall.r...@gmail.com wrote:
So the idea is that stable always corresponds to the latest stable
release.
Yes.
Will there be a branch where active development happens while
master is frozen?
I wouldn't think so. I'd just
I suggest the following branch model:
Development takes place on the master branch which is, some time
before the release, forked into a cabal-x.y branch. The cabal-x.y
branch will only receive bug fixes up til the release. General
development (i.e. new features) continue going in to the master
On Mon, Aug 27, 2012 at 2:00 PM, Andres Löh and...@well-typed.com wrote:
Apart from a fixed-schedule release cycle, how's this model different
from the model we use now?
I don't think it is. The release schedule is the important part for me.
___
On Mon, Aug 27, 2012 at 1:55 PM, Johan Tibell johan.tib...@gmail.comwrote:
Development takes place on the master branch which is, some time
before the release, forked into a cabal-x.y branch. The cabal-x.y
branch will only receive bug fixes up til the release. General
development (i.e. new
I don't think it is. The release schedule is the important part for me.
I'm not a huge fan of quarterly release schedules. They hardly leave
you any time to actually do anything. I'd much rather have a release
schedule that's predictably in sync with GHC releases, to prevent lags
as we had prior
We should bump the cabal-install package version to be the same as the Cabal
package version, and increment both at the same time. It's deeply confusing
to have the two out of sync.
Apart from 0 vs 1, this is already being done. I'm ok with bumping
cabal-install from 0.x to 1.x.
I'd like to
On Mon, Aug 27, 2012 at 2:09 PM, Andres Löh and...@well-typed.com wrote:
I'm not a huge fan of quarterly release schedules. They hardly leave
you any time to actually do anything.
That's not actually true. A release adds pressure to make the code actually
work, and having the code out in the
On Mon, Aug 27, 2012 at 2:09 PM, Andres Löh and...@well-typed.com wrote:
I don't think it is. The release schedule is the important part for me.
I'm not a huge fan of quarterly release schedules. They hardly leave
you any time to actually do anything. I'd much rather have a release
schedule
On Sun, 2012-08-26 at 22:27 -0700, Bryan O'Sullivan wrote:
We need to publish a new cabal-install 0.16 release shortly, ideally before
GHC 7.6.1 and the next Haskell Platform come out.
At the very least, there's a newish incompatibility between GHC 7.6 and
cabal-install that causes all
On Mon, Aug 27, 2012 at 2:31 PM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
I think help with managing the stable branch and making releases would
be very helpful indeed.
So how about Bryan, I, and whoever else feels like helping manage the
releases in the future? I'm acquiring a beefier
13 matches
Mail list logo
