Manage deck versions

What you’ll accomplish

Deck versioning helps you understand whether a change actually improved a list. By the end of this workflow you can save versions intentionally, compare them with analysis (not just card diff), and treat your testing history as a record you can learn from instead of a write-only stream.

Before you start

• A target deck with at least one analysis run — see Build decks and Analyze decks and scores.
• A change you want to try (a ratio shift, a tech swap, a side deck rebuild, a post-banlist update).

Steps

1. Snapshot before you tinker

   The moment you decide to test a change, save the current list as a version. Naming matters — v2 more starters tells future-you what you were testing; v2 test doesn’t.

   Good version names explain intent:

   • v1 import
   • v2 more starters
   • v3 locals side plan
   • v4 post-banlist
   • v5 budget cut, sub Pot of Greed

   Small typo fixes or card-name corrections don’t need a new version — they’re not decisions, they’re hygiene.

   Screenshot pending /img/docs/versioning/version-history-list.png

   Future-you reading this in three months will thank present-you for the labels.

2. Run Quick Analysis on both versions

   After making the change in a new version, run Quick Analysis on both versions. The point is the comparison — a single analysis tells you the current state but not whether the change helped.

   Screenshot pending /img/docs/versioning/version-quick-analysis-A.png

   Always analyze both versions before drawing a conclusion. One analysis is a number; two analyses are a delta.

3. Compare side-by-side

   Open the Compare view with both versions selected. The page shows:

   • Strategic takeaways at the top — “starter density up”, “answer density down”, “brick risk increased”
   • Coverage delta — the 5-dimension change visualized
   • Simulation delta — observed-rate changes
   • Raw card diff — at the bottom

   Read top to bottom. The takeaways are the conclusion; the raw diff is just the evidence.

   Screenshot pending /img/docs/versioning/version-compare-view.png

   Strategic takeaways first. The raw card diff is for confirming the read, not forming it.

4. Keep or revert

   The change improved structure → archive the old version with a note explaining why, promote the new one to active.

   The change hurt → revert. Keep the failed version around with a note about WHY it failed; future-you may have the same idea and need the receipt.

   The result is ambiguous (small numerical change, simulation noisy) → leave both, test in play, decide afterwards.

   Screenshot pending /img/docs/versioning/version-quick-analysis-B.png

   Numerical noise: a 2% simulation rate change inside a 10K-hand sample is often signal you can't lean on.

What success looks like

The deck’s version history reads as a coherent story — each version’s name explains why it exists, and any reverted versions have a note saying what didn’t work and why. Six months from now you can answer “why did I take this card out?” without re-deriving the reasoning from scratch.

Common pitfalls

• Editing the active version directly. No snapshot means no comparison means no learning. Save first, edit second.
• Deleting “failed” versions. They’re not failures — they’re records. The version that didn’t work explains why the current version is shaped the way it is.
• Using generic version names. v3 test tells you nothing in three months. v3 swap Maxx C → Ash tells you everything.
• Comparing only card diff without analysis. “I removed 3 cards and added 3” is evidence — not conclusion. The conclusion lives in coverage and simulation deltas.

Going deeper

Versioning interacts with readiness — a new version may have different shortage shape than the old one. The acquisition plan respects whichever version is currently active. Coverage and simulation deltas use the same model documented in Scoring model.

For the recommended cadence (when to version, when to just edit), see Recommended workflow.

For the field-by-field reference of the versioning surface — timeline, intent labels, compare picker — see Deck versions (reference).

Next steps

Compare and improve decks Use compare not just on your own versions but against benchmark lists.

Analyze decks and scores Re-read the analysis page with versioning context in mind.