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. Roan Kattouw (Catrope) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
