6.4Release trains

Once you have a main game and three editions, "ship 1.2" stops being one action and becomes four, spread over however long the slowest one takes. In the meantime players on the fastest store have a version nobody else has, and your support channel finds out before you do.

A release train is that whole operation as one object. It pins a single commit of the main game, integrates that commit into every participating edition, builds each one, and then waits.

Nothing uploads until everything is ready

A build that belongs to a train withholds its deploy. Left to itself, the Steam build would deploy as the last step of packaging and reach players hours before the Switch build finished — which is the exact thing a train exists to prevent.

Publishing is then one confirmed step that releases every store at once.

   pin commit #412
        │
        ├─► integrate ─► build  main / Steam      ✓ ready
        ├─► integrate ─► build  Switch            ✓ ready
        ├─► integrate ─► build  PlayStation       ⏳ building
        └─► integrate ─► build  demo              ✓ ready
                                                    │
                          gate: closed ─────────────┘
                                │
                     all green ─┴─► PUBLISH  (one confirmed step)

Versions stay per edition

Certification cycles put consoles out of lockstep, and a train that forced one version string across every platform would be unusable the first time a submission came back with a fix request.

So versions remain per edition. What a train guarantees is a shared commit, not a shared number — which is the thing that actually matters when you are trying to work out whether two builds contain the same fix.