On Fri, Apr 15, 2011 at 2:26 AM, Roan Kattouw roan.kattouw@gmail.comwrote:
2011/4/15 Tim Starling tstarling@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.
I'd be happy with about two weeks: push 'beta' tarballs in the first week, 'release candidates' in the second week.
In the meantime, we should be running 1.18 on live servers, with a maximum of a week lag from trunk, and preferably much less. Ongoing work on trunk should always be keeping stability in mind, and code review should concentrate on ensuring that code is being actively tested and used.
I know we had some delays due to wanting to finish the security fixes, but I'm extremely concerned that trunk hasn't been being maintained this way since the initial 1.17 push.
Unexercised code is dangerous code that will break when you least expect it; we need to get code into use fast, where it won't sit idle until we push it live with a thousand other things we've forgotten about.
-- brion