|Resolved||Legoktm||T67289 Use semantic versioning scheme for WMF (all) releases|
|Resolved||• GWicke||T102550 Use semantic versioning for services (for consistency with mediawiki core)|
|Resolved||mmodell||T94620 [EPIC] The future of MediaWiki deployment: Tooling|
|Open||None||T104398 Deploy MW+Extensions by percentage of users (instead of by domain/wiki)|
|Resolved||demon||T73313 Automatically clean up unused wmfXX versions|
|Declined||mmodell||T98834 Use subrepos instead of git submodules for deployed MediaWiki extensions|
|Declined||mmodell||T89945 Merge to deployed branches instead of cutting a new deployment branch every week.|
|Declined||None||T151470 Define a stable API for scap plugins|
|Resolved||mmodell||T142880 Create `scap swat` command to automate patch merging & testing during a swat deployment|
|Resolved||mmodell||T140918 create `scap branch` command (the successor to make-wmf-branch)|
|Resolved||mmodell||T142590 make scap3 look in PWD to find local CLI extensions|
@bd808: I kinda conflated two things in this one ticket. This is the result of discussion that occurred in a recent Release-Engineering-Team (Long-Lived-Branches) meeting between @demon, @thcipriani and myself.
My understanding as of now is that we decided to build two different utilities as scap extensions. We could call them scap merge and a scap swat, the former will merge all the changes for the weekly train, the latter will merge just one patch for the daily swat. They both need to do some slightly complex interaction with git & gerrit.
The thing we realized is that the two commands should be able to share share a lot of the same code. So we concluded that the clearest path forward would be to start by building the easier one (scap swat) and then use that as a basis to build the replacement make-wmf-branch. I should have created two tasks for them but instead I did the lazy thing and mixed them into this one task. I will correct that.