Page MenuHomePhabricator

Make make-wmf-branch able to branch extensions with replaced substring of the version of mediawiki being branched
Closed, InvalidPublic


Rather than having to manually update make-wmf-branch/default.conf (even more so now with the weekly branching and deployments), it'd be great if we could make the special extension versions a bit more dynamic if required.

$specialExtensions = array(
'DataValues' => 'mw1.22-wmf5',
'Diff' => 'mw1.22-wmf5',
'Wikibase' => 'mw1.22-wmf5',


$specialExtensions = array(
'DataValues' => 'mw-$wgVersion',
'Diff' => 'mw-$wgVersion',
'Wikibase' => 'mw-$wgVersion',

$wgVersion can be replaced inline by the code.

I'm not sure of the best way to lay this out.. Wikidata have been using a hyphen in the middle, which doesn't work so well with how $wgVersion currently is. Could we swap to say mw-1.22wmf5 via mw-$wgVersion? Or should try and support the current? Maybe with a major and a minor (major being 1.22, minor being wmf5) etc

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:05 AM
bzimport added a project: Utilities-Other.
bzimport set Reference to bz49392.

And of course, the simplest replace won't actually work for this, with Wikidata not updating every week...

greg set Security to None.

What is the the condition which determines when wikidata does update?

Our usual rhythm is every two weeks. However we might shift every now and then based on things like "we can't release this and that feature yet" or vacation.

I'm not sure why we branch each extension every week, it seems really redundant and actually counter-productive.

It seems like it would be better to just let each team decide on their own release cadence and simply tag a new release version every time they are comfortable releasing a new version. Branch update coordination could be handled by careful naming conventions on release tags so that the software can easily pick the newest appropriate extension tag for the corresponding core release.

What would we do with extensions without an active team?

@Krenair: the best match to what we are already doing:
Tag the latest commit on master when cutting the new release and point core's submodule pointer at that tag.

greg removed Reedy as the assignee of this task.Apr 8 2015, 10:29 PM
greg moved this task from To Triage to Backlog (Tech) on the Deployments board.

We'll need the changes to make-wmf-branch done pretty soon, we're only a week away from 1.27 branching....

Question: will the wiki page names change as well, I presume?

eg: should actually be to match the tag of "1.27.0-wmf.1"?

Question: will the wiki page names change as well, I presume?

eg: should actually be to match the tag of "1.27.0-wmf.1"?


That's fine, just need to know how to name the wiki pages :)

Due to the current plan to migrate to long-lived-branches (T89945: Merge to deployed branches instead of cutting a new deployment branch every week.) I think that make-wmf-branch should be considered deprecated. I'm not sure if this task should be closed as invalid or just modified to reflect the new state of the world.

Leaving it open for now.

With the new scap branch tool, this can be configured on a per-submodule basis to support the following branching actions:

branchNonecreate a new branch from master with the same name as the corresponding branch in rMW MediaWiki
checkoutref - a git ref or revisionCheck out the specified commit, tag or branch instead of branching
checkout-latestref- a pattern that matches candidate branches.Check out the newest branch matching the pattern in ref

This doesn't apply anymore since we have removed all support for special snowflakes.