If converting to Gadgets 2.0 goes awry and we have to switch everything back, we'll need a reverse migration script that formats the gadgets back to 1.0.
See https://gerrit.wikimedia.org/r/#/c/247869/ for existing Gadgets 2.0 code.
If converting to Gadgets 2.0 goes awry and we have to switch everything back, we'll need a reverse migration script that formats the gadgets back to 1.0.
See https://gerrit.wikimedia.org/r/#/c/247869/ for existing Gadgets 2.0 code.
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Introduce MultiGadgetRepo to facilitate repo migration | mediawiki/extensions/Gadgets | master | +173 -2 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Invalid | None | T34169 Action to join scripts and styles in one file | |||
Open | None | T110014 Make gadgets easily customizable (merge Gadgets' branch "gadgetprefs" from GSoC 2011) | |||
Open | None | T31272 Implement Gadgets 2.0 | |||
Open | None | T31398 Implement Gadget Manager | |||
Resolved | Krinkle | T140323 Create reverse migration script for Gadgets 2.0 |
Change 981622 had a related patch set uploaded (by Krinkle; author: SD0001):
[mediawiki/extensions/Gadgets@master] Introduce MultiGadgetRepo to facilitate repo migration
Change 981622 merged by jenkins-bot:
[mediawiki/extensions/Gadgets@master] Introduce MultiGadgetRepo to facilitate repo migration
With MultiGadgetRepo, adoption will be gradual with users having full autonomy at the individual gadget level. This means adopting a JSON gadget is as easy as creating the appropiate page (JSON will have precedence over the entry from the legacy definition page). And switching back would involve deleting or moving said page, or changing its content model, so as to not be loaded.
I imagine in most cases, people will choose not to eagerly delete the old definition, so that should naturally offer an easy way back.