New cabal-install release (and schedule) needed

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 -Werror builds to fail because cabal-install uses a deprecated package flag. This was fixed back in May, but that needs to actually go out into the wild. Stepping back, I'd also like to suggest that we move to a quarterly release cycle on a simple, widely used model. A major goal here is to get code into people's hands on a predictable schedule. We maintain two branches, stable and master. Master freezes a month before a release, with only bugfixes and typo fixes going in. At release time, the stable branch opens (in case any emergency fixes are needed), and master opens up for normal development again. Johan and I are happy to do the work to manage these cycles. I suggest that we start the first cycle with a target release date of the end of September, then go four months to the next one (after all, it would be unrealistic to pretend that we might do a release at the end of December). Does this sound reasonable?

Hi Bryan,
On Mon, Aug 27, 2012 at 7:27 AM, Bryan O'Sullivan
[...] 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 proprietary attachments

On Mon, Aug 27, 2012 at 8:30 AM, Mikhail Glushenkov < the.dead.shall.rise@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 (although I'd be astonished if we ever cut a release from the stable branch in the few weeks while master was frozen);

Hi,
On Mon, Aug 27, 2012 at 6:08 PM, Bryan O'Sullivan
On Mon, Aug 27, 2012 at 8:30 AM, Mikhail Glushenkov
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 (although I'd be astonished if we ever cut a release from the stable branch in the few weeks while master was frozen);
So the idea is that stable always corresponds to the latest stable release. Will there be a branch where active development happens while master is frozen? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

On Mon, Aug 27, 2012 at 10:35 AM, Mikhail Glushenkov < the.dead.shall.rise@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 expect people to delay pull requests for a little while during a freeze, to keep things simplest for the people involved. (Yes, we could have three branches instead, but I'd prefer to try the simpler structure to begin with.)

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 branch at all times. We need to merge bug fixes from the cabal-x.y branch back into master, at a minimum after the release of that branch. The benefit here is that we don't disuade people from contributing by holding their patches in review limbo for a month. Also, it reduces the merge pain if everyone tries to merge their patches at once after a month of development. -- Johan

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 branch at all times. We need to merge bug fixes from the cabal-x.y branch back into master, at a minimum after the release of that branch.
The benefit here is that we don't disuade people from contributing by holding their patches in review limbo for a month. Also, it reduces the merge pain if everyone tries to merge their patches at once after a month of development.
Apart from a fixed-schedule release cycle, how's this model different from the model we use now? Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com

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 to the cabal-install-0.14 release. Regarding the need for a release of 0.16 very soon, I completely agree. Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com

On Mon, Aug 27, 2012 at 2:09 PM, Andres Löh
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 wild gives useful feedback to people who are doing the work in the first place. A long release cycle decouples writing code from seeing anyone use it, which seriously deflates the incentive to do any work in the first place. I already work on a busy open source project that has quarterly releases, and it works just fine, up to and including large modifications. I'd much rather have a release
schedule that's predictably in sync with GHC releases,
Quarterly releases can easily be synced to GHC releases. The two are not in conflict.

On Mon, Aug 27, 2012 at 2:09 PM, Andres Löh
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 to the cabal-install-0.14 release. Regarding the need for a release of 0.16 very soon, I completely agree.
Here's the list of Cabal library releases for the last few years, including their release date: 1.14.0.0 Thu Feb 2 2012 1.12.0.0 Tue Jan 31 2012 1.10.2.0 Sat Jun 18 2011 1.10.1.0 Thu Mar 3 2011 1.10.0.0 Tue Nov 16 2010 1.8.0.6 Tue Jun 15 2010 1.8.0.4 Wed Mar 31 2010 1.8.0.2 Wed Dec 16 2009 1.6.0.3 Thu Apr 9 2009 and for cabal-install 0.14.0 Tue Apr 17 15:47:57 UTC 2012 0.10.2 Wed Mar 9 00:14:20 UTC 2011 0.10.0 Thu Mar 3 15:02:44 UTC 2011 0.8.2 Wed Mar 31 12:11:59 UTC 2010 0.8.0 Sun Dec 20 00:50:38 UTC 2009 0.6.4 Sat Nov 28 03:54:30 UTC 2009 0.6.2 Thu Feb 19 15:30:33 UTC 2009 I think we need more frequent releases for two reasons: * It give people and incentive do stuff. Trying to improve cabal in order to improve your own use of it, knowing that it will take 6+ months to be able to make use of the improvement isn't very motivating. * We need to fix bugs. Waiting 6 months for a bug fix is not OK. For example, there were a couple of regressions in the last release (i.e. profiling code not building correctly due to GHC not being passed the right arguments) that have been fixed but not released. Generally I'd expect any bug that affects a larger number of users to cause another release no more than a week or two after it has been fixed. -- Johan

On Mon, Aug 27, 2012 at 1:55 PM, Johan Tibell
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 branch at all times. We need to merge bug fixes from the cabal-x.y branch back into master, at a minimum after the release of that branch.
That sounds fine to me. Other small details: - 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. - I'd like to get rid of some old named branches that no longer have any value, e.g. cabal-1.2. Keeping tags around for a long time makes sense, branches do not.

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 get rid of some old named branches that no longer have any value, e.g. cabal-1.2. Keeping tags around for a long time makes sense, branches do not.
Yes, I don't really see a problem there. Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com

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 -Werror builds to fail because cabal-install uses a deprecated package flag. This was fixed back in May, but that needs to actually go out into the wild.
Stepping back, I'd also like to suggest that we move to a quarterly release cycle on a simple, widely used model. A major goal here is to get code into people's hands on a predictable schedule.
We maintain two branches, stable and master. Master freezes a month before a release, with only bugfixes and typo fixes going in. At release time, the stable branch opens (in case any emergency fixes are needed), and master opens up for normal development again.
Johan and I are happy to do the work to manage these cycles.
I suggest that we start the first cycle with a target release date of the end of September, then go four months to the next one (after all, it would be unrealistic to pretend that we might do a release at the end of December).
Does this sound reasonable?
I think help with managing the stable branch and making releases would be very helpful indeed. I did used to do more frequent releases but it's a time consuming task. I'd certainly prefer to spend time on patch review, cleaning up old code and adding new features. BTW, I'm no longer on honeymoon and I've nearly finished rewriting the bytestring I/O layer so I hope to have a bit more time for cabal patch review and hacking. Duncan

On Mon, Aug 27, 2012 at 2:31 PM, Duncan Coutts
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 server machine at the moment and we can use it to set up various automated QA tests* to make sure we feel more comfortable making releases and that making releases takes less time. * You might have seen my emails about the buildbot before. Turns out that my Linode VPS wasn't powerful enough and make ghc segfault, leading to spurious error reports from Jenkins. This should be fixed with this new machine.
participants (5)
-
Andres Löh
-
Bryan O'Sullivan
-
Duncan Coutts
-
Johan Tibell
-
Mikhail Glushenkov