On 15/04/11 04:22, Roan Kattouw wrote:
2011/4/14 Mark Hershberger
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
* 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