On 15/04/11 19:26, Roan Kattouw wrote: > 2011/4/15 Tim Starling <tstarl...@wikimedia.org>: >> My preference is for 2 to 3 major releases per year. We branched 1.17 >> in December and we're looking at doing a release in April. So a 4 >> month cycle would imply branching 1.18 in April and releasing in August. >> >> I don't think having 4 or 5 major releases per year would serve anyone >> particularly well. A slower release cadence means: >> > I can get on board with having 3 releases per year, but I'll reiterate > that 3 months, let alone 4, between branching and releasing is too > long. Yes, 1.17 took 4 months to stabilize, but it was 10 months' > worth of code, so that's a 1:2.5 ratio. Interpolating that suggests > that a release with 4 months' worth of code can be prepared in less > than 2 months, and I think that once code review is organized properly > such that large backlogs don't happen anymore (we had a very large > backlog for 1.17 and I think we'll have a comparable one, considering > the difference in elapsed time, for 1.18, but I'd really like to have > this organized properly for 1.19 or 1.20), we can do better than that. > > Instead, you're proposing a 1:1 workflow where, at any given point in > time, we always have a release branch that's being stabilized, which > means we have to perpetually maintain three branches (trunk, > deployment, release) instead of two, and are always in the process of > preparing a release. I don't like that idea, and I think it's > unnecessary.
That's a fair point. I didn't mean to propose a 1:1 workflow, I meant to just make a point about release schedules. I know that different developers have different ideas about branch point schedules and how they should relate to release schedules. I don't have a strong view at this stage. -- Tim Starling _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
