- ./branch.py REL1_39 --bundle base --branchpoint master (branch tarball extensions and skins)
- ./branch.py REL1_39 --core --branchpoint master --core-version 1.39.0-beta --task T313920 (branch MW itself and make a sub-module commit)
- ./branch.py REL1_39 --bundle '*' --branchpoint master --core-version 1.39.0 (branch all other extensions and skins)
Description
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Reedy | T313916 Release MW 1.39.0 | |||
Resolved | Jdforrester-WMF | T313920 Branch REL1_39 for MediaWiki and all extensions and skins |
Event Timeline
Mentioned in SAL (#wikimedia-releng) [2022-09-06T02:05:09Z] <James_F> Running REL1_39 branch commands for T313920
Change 829873 had a related patch set uploaded (by Jforrester; author: Jforrester):
[mediawiki/core@REL1_39] Branch commit for REL1_39
Change 829874 had a related patch set uploaded (by Jforrester; author: Jforrester):
[mediawiki/core@master] Prepare active branch following REL1_39 cut, labelling as 1.40-alpha
Change 829873 merged by Jforrester:
[mediawiki/core@REL1_39] Branch commit for REL1_39
Change 829876 had a related patch set uploaded (by Jforrester; author: Jforrester):
[mediawiki/core@REL1_39] Update composer.json and dbal hacks to drop PHP 7.2 support
Change 829874 merged by jenkins-bot:
[mediawiki/core@master] Prepare active branch following REL1_39 cut, labelling as 1.40-alpha
Change 829876 merged by Jforrester:
[mediawiki/core@REL1_39] Update composer.json and dbal hacks to drop PHP 7.2 support
rel1_39 was only branched on CORE, not skins or extensions. and there hasn't been a REL branch for those since REL1_35. When attempting to update to the most current LTS it is not possible to match CORE checkout and extension/skin checkouts. This will cause compatibility issues at some point.
You're confusing two seperate things.
For example, AbuseFilter:
reedy@MacBook-Pro-2 AbuseFilter % git branch -a * (HEAD detached at 54281c36) master remotes/gerrit/REL1_19 remotes/gerrit/REL1_20 remotes/gerrit/REL1_21 remotes/gerrit/REL1_22 remotes/gerrit/REL1_23 remotes/gerrit/REL1_24 remotes/gerrit/REL1_25 remotes/gerrit/REL1_26 remotes/gerrit/REL1_27 remotes/gerrit/REL1_28 remotes/gerrit/REL1_29 remotes/gerrit/REL1_30 remotes/gerrit/REL1_31 remotes/gerrit/REL1_32 remotes/gerrit/REL1_33 remotes/gerrit/REL1_34 remotes/gerrit/REL1_35 remotes/gerrit/REL1_36 remotes/gerrit/REL1_37 remotes/gerrit/REL1_38 remotes/gerrit/REL1_39 <snip>
This is compared to the extensions "meta" repo:
reedy@MacBook-Pro-2 extensions % git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/REL1_23 remotes/origin/REL1_27 remotes/origin/REL1_28 remotes/origin/REL1_29 remotes/origin/REL1_30 remotes/origin/REL1_31 remotes/origin/REL1_32 remotes/origin/REL1_33 remotes/origin/REL1_34 remotes/origin/REL1_35 remotes/origin/master
Which is maybe T264365: mediawiki/extensions and mediawiki/skins missing the REL1_XX branches
You are correct I was referring to the meta repos. Normally you just set the REL correct and check out the entire repo, then enable extensions on an as needed basis. Avoids having to do 10+ separate checkouts.
The meta-repos haven't been branched since REL1_35; the right venue for this is T264365, sorry. Meta-repos are a gerrit-only thing used only for developer convenience, and so I imagine they're going away in a GitLab land anyway, sorry.