Branches, releases and version numbers

Muppy ships from a single customer branch, releases one lot of work at a time, and numbers every build so the number alone says what you are running.

Three kinds of branches

18.0 — the customer branch. What customers run. It receives merges of the integration branch and hotfixes, nothing else. Every release is cut here.

next — the integration branch. Permanent. A lot lands here when it is accepted: its walkthrough and its review checklist are done, on the integration environment.

Lot branches. One branch, one lot of work. Born from next, deleted when they merge.

A hotfix is committed on 18.0, released as a patch, and merged into next straight away, so the next merge cannot undo it.

A lot is released when it is accepted

A lot accepted on next is merged into 18.0 and released. It does not wait for another lot.

The rule exists because waiting compounds. A lot held back collects the tests of every lot queued behind it, and when it finally moves, one release carries months of unrelated change. That is a big-bang release — the thing customers must never receive. One lot, one merge, one release keeps each release small enough to read, and small enough to undo.

Version numbers

A number is MAJOR.MINOR.PATCH, tagged in git.

• MAJOR is the Odoo series Muppy runs on: 18.
• MINOR bumps each time the integration branch merges into 18.0.
• PATCH bumps for a hotfix on 18.0.

One rule governs every number, and it has no exception: a release number is greater than every tag the release contains, branch builds included. No parity, no reserved number, no number announced before it is cut.

You see	What it is
18.89.0	a release — it has a page here
18.89.1	a patch on 18.89.0 — documented on the page of 18.89.0
18.89.0-beta.next.7	a branch build — the seventh build of next after 18.89.0
18.89.0-1-gdf5cd050	a checkout one commit past the release 18.89.0
df5cd050	a build from a branch that carries no tag at all

Branch builds

A build tagged on a branch is <base>-beta.<branch>.<n> — 18.89.0-beta.next.7, 18.89.0-beta.mkeyd.3.

• <base> is the last release the branch contains. It is a fact git computes, not a promise about the number the work will be released under. When the branch absorbs a new release, <base> moves with it.
• beta is always the first identifier of the suffix. The CI/CD reads it to pick the deployment profile, so it does not vary.
• <branch> is the branch name, underscores written as hyphens — a version suffix admits only letters, digits and hyphens.
• <n> counts the builds of that branch.

A branch build is never released and never gets release notes. It exists so a test, staging or integration server can run a lot before that lot is a release.

Sub-repositories

Muppy is assembled from sub-repositories, each with its own git history. A lot that needs a change in one of them gets a twin branch there, pinned in the build file (.muppy/buildit.jsonc), for exactly as long as the lot lives.

The pin is born with the lot branch and dies with it: merging a lot back merges its twins in the same gesture, and nothing named after a dead branch survives, in any repository. A surviving pin is a server still building from a branch nobody maintains.

What you see as a user

• One page per MINOR under Release Notes. It says what the release changes for you.
• A patch adds a section to the page of its minor. It never gets a page of its own.
• A branch build has no page. Read the page of the release it is based on, and treat what follows as work in progress.

The version in the user menu links to its release page. For anything that is not a release, it links to how to read a version number.

Where to read your version

The version of the instance you are using is in the user menu, top right. The instance also serves it at /inouk_health_check — the form to use from a script, or to check a server you are not logged into.