Migrating from MergeFreeze

This page is a compatibility note, not a pitch. If your current freeze tool works, that is a good reason to keep it; what follows is what the compatibility namespace does, for people who have already decided to move. There is no importer of your repository list or schedules. It is not built, so this describes what works today.

Three steps

1. Install Fwozen alongside your current tool and enable the same repositories. Nothing breaks while both are installed: two required checks both have to pass. Recreate your schedules in the Fwozen schedule builder, which shows the next five occurrences in the schedule’s timezone and in yours before you save. Enrolling a repository needs no email request to us; you install the App and enable what you want.
2. Create an API key. Settings → API keys → Create key, with freeze:read and freeze:write, plus repo:write if your scripts enrol branches and exception:write if they unblock pull requests. The secret is shown once. This is the one thing that does not carry over: Fwozen keys start with fwz_, and the compatibility namespace refuses anything else with a 401 rather than pretending to recognise it.
3. Change one base URL and the token behind it. Paths, query parameters, request bodies and response field names stay as they are.

# before: your current tool's API base, the part before /branches
BASE_URL=…/api
TOKEN=mfo_…

# after
BASE_URL=https://api.fwozen.com/api/compat/v1
TOKEN=fwz_live_…

What the namespace answers

• GET /branches/{account}/{repo}/{branch} — the freeze state of one branch, in the old field names. A repository it cannot see answers {} rather than a 404, which is the quirk your scripts already handle.
• POST /branches/{account}/{repo}/{branch} — freeze or thaw with frozen, plus note, user_name, allow_deployments and unblocked_prs. Form-encoded or JSON, either way. Freezing something already frozen answers 200 with a warning, not an error.
• POST /branches — enrol a repository and start watching a branch.
• DELETE /branches — stop watching one.
• POST /scheduled_freezes — a one-off window from one_off_freeze_at and one_off_unfreeze_at, in epoch seconds.
• GET /freeze_logs — freeze history, with actor, actor_type, reason and duration_seconds added to each row. Additive, so a reader that ignores unknown fields is unaffected.
• POST /generate_access_token — answers 400 compat_feature_removed. See below.

Two behaviours deliberately not reproduced

• Minting a token from a token. An API key can never mint another API key here, whatever namespace it is called through. Create keys in the dashboard.
• Revoke-by-omission on unblocked_prs. Sending the list is additive: a pull request you leave out of a later call keeps its exception rather than silently losing it. Revoke an exception explicitly, in the dashboard or through /v1. Fwozen also requires the key to carry exception:write for that field.

What you keep, what you lose, what you gain

• You keep your scripts, your freeze and thaw semantics, your field names, and the ability to run both tools at once while you check.
• You lose, today, an importer for your repository list and schedules, and your years of freeze history: the audit log starts on the day you install. There is no Mac menu-bar app.
• You gain enforcement Fwozen reads back from GitHub per branch rather than assumes, merge-queue freezing, deploy gating through a required check and a published Action, per-PR exceptions with a reason and a time limit, and an audit log with a named actor on every row.
• Stay where you are if what you have works and nobody has been surprised by a merge during a freeze. That is a real answer, and the honest case against code freezes is the argument against the whole category, written by us.

The compatibility namespace exists because breaking someone’s scripts is a bad way to be chosen. It stays supported whether or not you keep the other tool installed. When you are ready, remove the old app’s required check from your branch rules and uninstall it, and leaving Fwozen is written down too.