To keep a Commander deck version history, save the current list before making changes, assign the revision a date or version number, record each card added and removed, and write one sentence explaining the goal. Log future games against that revision until the list changes again.
The minimum version record
| Field | Example |
|---|---|
| Version | v4 |
| Effective date | 2026-04-09 |
| Cards added | 2 flexible removal spells; 1 untapped land |
| Cards removed | 2 seven-mana finishers; 1 tapped land |
| Reason | Reduce stranded opening cards and improve early interaction |
| Baseline | v3: 4 wins in 18 comparable games |
Write a hypothesis, not “upgrades”
“Made the deck better” cannot be tested. Write what should change in play: fewer missed colors, more actions before turn three, better recovery after a wipe, or a shorter gap between establishing control and winning. The reason tells you which signal to review later.
Choose useful version boundaries
Create a new version when cards enter or leave the list. If ten swaps happen during one editing session before another game, keep them together. Do not create empty versions for formatting or sideboard ideas. A major rebuild can retain the deck's identity while receiving a clear milestone such as “v10 — new artifact plan.”
Preserve previous lists rather than overwriting them. A decklist service, spreadsheet, or text export can store the complete 100; a compact changelog provides the readable history.
Connect games to the list actually played
The current decklist cannot explain a game from six months ago. Include the version ID in every game log, along with pod size, opponents, result, and final turn. WUBRG is built around this connection: card swaps form versions and game records stay associated with the relevant stage of the deck.
Compare versions without fooling yourself
Display games and wins, not only percentages. Compare similar power environments and allow enough games for variance. If v4 went 4–2 after v3 went 4–14, investigate—but six games do not prove every swap worked. Check the hypothesis directly: were fewer high-cost cards stranded? Did the deck hold interaction earlier?
Pilot learning is another confounder. A later version may perform better because you learned the deck. Record that possibility rather than assigning all improvement to new cards.
Revert confidently
A version history makes reversals cheap. If a revision weakens the theme, worsens mana, or creates games the group dislikes, restore the previous list or reintroduce selected cards. Reverting is not failure; it is a result from a documented test.
Deck-version FAQ
Should every single card swap create a new version?
Yes once that swap is played, but group all edits made before the next game into one version. The goal is to identify the exact list used for each result.
How many games should a deck version get?
Aim for 10 games before a broad judgment and closer to 20 for an early comparison, unless testing reveals an obvious mana, legality, or functionality issue.
Should a complete rebuild become a new deck?
Use a new deck when the commander, core identity, or intended history changes. Keep a new version when you still want the rebuild compared with the same deck's past.