Upgrade drill: what breaks, and how long a rollback takes
Experiment design set, results await raw records
This page gives only the experiment design, not the results. Numbers we haven’t run are never written; paste raw records into the table after running, then write the conclusion.
Question to answer
Upgrading DSH from one channel version to the next on a local machine: which step breaks existing plugins and config, how long does a rollback take, and does it restore the previous state?
Control groups
Four sequential steps: full snapshot, upgrade, enable plugins one at a time with a minimal task, roll back. Timestamp every step and keep going after a failure rather than skipping it.
Environment & version
- Host version
- To fill
- Model ID
- To fill
- Mode / permissions
- Keep both groups identical
- Input files
- Record hashes so both runs use the same files
Fields to log
| # | Field | Result |
|---|---|---|
| 1 | From and to versions, including channel | to be tested |
| 2 | Backup location, size and checksum | to be tested |
| 3 | Upgrade command and duration | to be tested |
| 4 | Startup error text after the upgrade | to be tested |
| 5 | Per-plugin result (works / version gate / error / silently dead) | to be tested |
| 6 | Whether config files were rewritten (diffed against the snapshot) | to be tested |
| 7 | Rollback command and duration | to be tested |
| 8 | Whether plugins and config came back exactly | to be tested |
Conclusion
To be tested. Any conclusion must also state what it can't generalize to.
Why we don’t write results yet
This records a drill only; nobody should upgrade a production machine from it. Do not bypass a version gate by editing a manifest: that just moves the breakage to the next upgrade.