Rob Lanphier wrote:
On Mon, Sep 20, 2010 at 4:01 PM, MZMcBride z@mzmcbride.com wrote:
Quite a few people are under the impression that MediaWiki 1.17 will be released in October or November of this year.
I don't think there's been many public references to this, but that is more or less the timeframe many of us have discussed. There is at least one public reference here: http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14
Thank you for this. I'm sure a lot of people will be watching the root page with a lot of interest. I agree with a lot of the other posters in this thread that publicly posting notes like this is a really good step in the right direction. :-)
Several of us have a desire to get back on a more regular release cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed like a good place to start.
I think there's a much greater desire for the live Wikimedia sites to be updated more regularly, far more than MediaWiki being released more regularly. Not that they're mutually exclusive, though with the current branch system, I suppose they could be, which raises further questions.
The goal, as I recall, was branching October 15 or thereabouts, with first beta in November, and a release sometime after that (perhaps as late as January, depending on how well we do with the first beta). We really haven't had an organized discussion of the topic since that one meeting above, but maybe this email thread can be that conversation. Nothing about the schedule is carved in stone, so now is as good a time as any to bring up any objections to that timeline.
Personally, I see a rough parallel between the concept of FlaggedRevs on a wiki and the current code development cycle. Nobody wants to make a contribution if it's going to sit in a queue indefinitely. It's much more satisfying to see your work (bug fix, article fix, whatever) go live in a relatively short amount of time.
Has there been any discussion about killing the branch system altogether?
From my perspective, the initiation of branching has slowed down code pushes
dramatically. This may be a false correlation I'm drawing, but I don't think so. There isn't nearly as much incentive to fix trunk when the branches are stable. But with that stability comes very little code development, aside from high priority Wikimedia Foundation projects being pushed into the branches directly by a few people. It also creates a lot more work (and commit noise) to merge from trunk rather than keeping trunk up and relatively stable (or stable enough to run the live sites). Has it been raised that going back to how things used to be might be better?
MZMcBride