Game release planning guide

1. Start with the changes

Open a release and enter the game name, release title, version, channel and player-facing summary. Add a rollback plan in the private field. A version can contain letters, numbers, dots, hyphens, plus signs and underscores; it is not required to follow semantic versioning.

In Release notes, expand Import a commit log. From your repository, produce a log with git log --format="%H%x09%s" and paste the output or select a UTF-8 .txt or .tsv file. Each line must contain a complete 40- or 64-character hexadecimal hash, a tab and a subject.

Imported UTF-8 sources retain their exact bytes, including an optional byte-order mark and CRLF line endings. UTF-16 files and invalid Unicode are rejected. Convert unsupported files to UTF-8 before import.

The preview maps feat: to Added and fix: to Fixed. Other supported conventional prefixes become Changed. Documentation, test, build, CI and maintenance commits start as private notes. Breaking-change markers are retained. Review the proposed notes before adding them. Matching hashes are skipped; conflicting subjects are rejected.

You can edit note text, change its category and choose whether it appears in public exports. Manual notes need a private source or verification note before approval. Original imported commit sources remain available for inspection.

2. Connect targets, builds and evidence

Add each platform target and its private destination or branch. For a target requiring a build record, select a file to compute a SHA-256 checksum on your device. The binary is neither uploaded nor stored in the workspace. Files larger than 128 MB can be represented by a declared checksum and byte count, clearly labeled as supplied by you.

A checksum identifies file contents. It does not show that a build is safe, signed, installed correctly or approved by a store. Record those separate checks with an owner and evidence. Required checks must be Done. Optional checks can be waived with a named owner and reason. Changing a check definition resets its completion; review the remaining checks whenever a build or target changes.

Use Reviewed versions to save the complete plan with a reviewer and approval note. Draft edits after approval do not change an earlier snapshot. Reusing a version and channel in another reviewed release within the same game is rejected.

3. Choose the right export

Public ZIP: Markdown and HTML release notes, a plain-text announcement, public release JSON and a readme. It contains notes and build records you explicitly included as public. Commit logs, reviewer identities, task evidence, target destinations and internal notes are excluded. Review the text and any build URL before sharing; public text can still contain anything you typed.

Private handoff ZIP: the reviewed plan, private checks and rollout CSVs, original commit logs, public notes and the planned calendar window. Treat it as an internal team document. No binary files are bundled.

Backup: complete workspace JSON, including private sources and history. Restore checks the structure and original commit-source SHA-256 digests before asking to replace the current workspace. A checksum detects corruption; an editable local backup is not a signed or tamper-proof audit record.

Use the HTML release notes with your browser's print command to save a PDF. JSON and CSV exports are available for your own tooling. CSV cells that could be interpreted as spreadsheet formulas are escaped.

4. Keep an honest rollout record

Set an optional planned start in UTC and a window length of 1–1,440 minutes. The calendar export uses a stable release identifier and a revision number so supporting calendar tools can identify an updated plan. Calendar applications vary in how they import updates; check for duplicates. This file does not schedule a storefront publication.

After approving a plan, record actions performed outside Launch Manager. Targets begin with no rollout recorded. Deployment can be followed by a verification, failure or rollback record. Each event requires an actor, timestamp, evidence and note; events cannot be entered out of timestamp order for the same target and reviewed version. A rolled-back target requires a new release plan for another rollout.

All statuses are user records. No storefront is connected and the app does not independently verify that a build is live.

Privacy, storage and limits

Workspace content is processed on your device and saved in this browser's IndexedDB. The app has no data-upload endpoint, analytics or account service. The hosting provider receives ordinary page and asset requests. Clearing site data, using a different browser or losing the device can remove access to your work. Download backups regularly and keep private exports in a trusted location.

Concurrent saves use a storage revision check so another tab cannot silently overwrite a newer workspace. If saving fails, keep the tab open, export a backup and follow the recovery message. Erase device workspace replaces the local workspace with an empty one; it does not delete previously downloaded files.

Limits: 5 games; 12 releases per game; 8 reviewed versions, 200 notes, 80 checks, 12 targets, 24 build records, 10 commit sources and 200 rollout events per release. Each source is limited to 100,000 characters; uploaded source files to 1 MB; the complete workspace and backup to 20 MB. File checksums are computed for selected files up to 128 MB. No GPT calls are used.

This free preview has no subscriptions or one-time payments. Cloud accounts, team permissions, direct storefront publishing, scheduled background jobs and connected billing are not available yet.