On 15/04/11 04:22, Roan Kattouw wrote:
2011/4/14 Mark Hershberger mhershberger@wikimedia.org:
Sorry, I should have been clearer. Yes, branch now(ish) and then aim for a 1.18 release on July 15th. My idea is that setting a date for the release to be soon and early would provide the motivation to the people involved in code review to keep it up-to-date.
The point I was trying to make was that July is by no means "soon and early" in my book. It's three months away, which is way to long. Setting a date is nice, but if we can get a release out before the set date, that's a good thing, and I think we can (and /should/) get 1.18 out way faster.
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:
* Less hassle for non-Wikimedia users, since upgrades between major releases require more work. Extensions break, patches break, DB upgrades need to be done.
* Less branches to backport to. This reduces the amount of work that needs to be done to backport security fixes and other bug fixes. We drop support for branches based on time elapsed, not number of versions released.
* Less branches to test against. If you're writing an extension that is meant to work on multiple MediaWiki versions, it will be easier if there are less versions that you need to test against, and potentially write special-case code for.
* It's easier to do major projects in trunk. When you merge work in to trunk from a development branch, it's necessary to stabilise the code before the next release. This can take a long time for a major project. Both the new installer and the resource loader benefited from a long release cycle in this way.
* More opportunity for whole-project review. When a project begins and ends in a single release cycle, reviewers can wait for the project to reach a state where the original developer is happy with it before they start reviewing and giving comments. This means that the reviewer doesn't have to spend so much time looking at intermediate commits.
-- Tim Starling