Upgrade a module and keep your changes

A release of a module is a new edition of it (an update), with its changes in plain words, such as "Each task has Steps: short lines in their order, each with a Done tick." Your base knows the release of each of its modules (See your base’s modules and those you can add).

• Your base takes each new release by itself, and keeps your changes, unless something stops it (How your base upgrades by itself). Then it waits until someone who builds the base applies it.
• Each module upgrades on its own: upgrading Hair salon leaves your other modules at their releases.
• One exception: when the new release changes something that another module of your base reads, such as a field of Orders that Event tickets uses, that module does not work without the release. Then the upgrade takes that module to its latest release too, in the same change, saved as one version. The window names it: "Upgrades Orders to release 10, with Event tickets."
• When the new release needs a module your base does not have, the upgrade installs that module first, in the same change.
• When the new release needs a newer release of a module your base has, the upgrade stops and says which module to upgrade first, such as "Upgrade Reports first: release 23 of Hair salon needs its release 10." Upgrade that module, then this one.

When a module gets a new release, each base that has the module upgrades to it by itself, one base after the other. The upgrade is one change to the base, saved as one version, and everyone who builds the base gets a notice with the release's changes.

When the release takes other modules along (What a new release of a module brings), they upgrade by themselves with it, in the same change and the same version. The notice says so, such as "Orders is at release 10, with Event tickets", and gives the changes of each module under its name.

When a release waits for you

The release waits for someone who builds the base, and they get a notice that says why, when:

• the release changes a value that your base changed too;
• the release changes who sees what (a role, or a rule on items or fields), so an admin must approve it;
• the release changes a part that your base's own code uses, such as a field that an automation names;
• the release needs a newer release of another module of your base, which someone must upgrade first;
• the release failed on your base;
• the upgrade takes along a module whose new release cannot go in by itself, because you undid that release or it failed on your base;
• the switch Upgrade modules automatically is off.

If a release fails on a base, that base keeps the modules it has, and the release waits for someone who builds the base. The other bases still get the release.

Turn off automatic upgrades

The switch Upgrade modules automatically is in Settings, Modules, and it is on in a new base. Only an admin can change it. If you turn it off, the builders get a notice about each new release, and someone who builds the base applies it.

The upgrade window shows what a module's new release changes in your base before anything happens. Someone who builds the base opens it: in the base, click Settings, then Modules. A module with a newer release shows its release and Upgrade. Click it. The window shows:

• the changes of each release since yours, in their own words. When the upgrade takes other modules along, the window shows the changes of each module under its name;
• what the upgrade does to your base, line by line, as for any change;
• the parts the release dropped. An upgrade never removes them: they stay in your base, and the window names them, such as "The field Visits.Old notes, which release 2 dropped";
• the places where you and the release both changed the same thing, for you to choose.

What only the release changed is taken. What only you changed is kept. A list, field, view or rule you added yourself, or that came from another module, is yours and stays.

Where you and a module's release both changed the same thing to different values, such as the title of a field you named "Budget (EUR)" and the release named "Fee", the upgrade window shows the three: what it was, yours and the release's. Pick one:

• Keep yours: your base stays as it is there.
• Take the release's: the release's value replaces yours.

When the release adds a list whose name your base already uses for another list, such as Meetings, pick Keep yours, skip the release’s, or Add it under a new name, such as "Meetings 2", and both are kept.

Every choice is made before you apply. If your choices together would leave the base broken, the window says why, so you can choose otherwise or ask the assistant to fix it.

To apply a module's upgrade, in the upgrade window:

1. Make your choice for each place where you both changed something.
2. Click Apply. Base Captain says the module is upgraded.

The upgrade is one change to the base, saved as one version, with the modules it takes along. In Activity, Versions, Restore brings the base back to just before it, for an hour after it, and the release shows as available again (Go back to an earlier version of the base). An upgrade that your base took by itself has Undo upgrade, with no time limit (Undo an upgrade).

An upgrade that your base took by itself can be undone. In Settings, Modules, such a module shows "Upgraded by itself to release 16" with the date, and Undo upgrade.

1. Click Undo upgrade.
2. The window shows what the undo changes and names the parts that the release added, which go with their data.
3. Click Undo upgrade in the window to confirm.

• The base goes back to the earlier release of the module.
• When the upgrade took other modules along, the undo takes all of them back together, each to its earlier release. The window names them: "Undoes the upgrade of Orders to release 10, with Event tickets." Undo upgrade on any one of these modules does the same.
• The changes that you made after the upgrade stay.
• The release you undid does not come back by itself. You can still apply it with Upgrade. The module's next release upgrades your base by itself again.
• You can undo the upgrade until your base installs, removes or upgrades a module again. After that, the undo would lose that change, so Undo upgrade is gone.

You can also ask the assistant: "Undo the upgrade of Hair salon". It shows the undo on a card first.

Ask the assistant to upgrade a module at any time: "Upgrade Hair salon to its new release".

• The assistant proposes a choice for each place where you both changed something: keep yours, take the release's, or a value that joins the two, and tells you each.
• It shows the release's changes, its choices and what the upgrade does on one card. Nothing happens until you click Apply.

Its work uses the plan's AI, as any of its work does.

Module upgrades keep these rules:

• A base made from an app of your own does not upgrade by itself. A base made from an app of your own has no built-in module to upgrade, until you install one.
• If someone changed the base while you were reading the upgrade window, the window loads the new plan again.

Under the API token of someone who builds the base, GET /api/builder/modules gives each module's release and its latest. POST /api/builder/modules/preview with "action": "upgrade" gives the plan: the releases' changes of each module it upgrades, what it changes, the parts kept and the conflicts, with your choices. POST /api/builder/modules with the same action applies it.

"action": "undo" does the same for an upgrade your base took by itself, with "confirm": true when it deletes something. Each module's auto says which upgrade you can undo, and waits says why a release waits.

Through Base Captain's MCP server, list_modules shows the releases, upgrade_module upgrades a module, with the modules it takes along, and undo_module_upgrade undoes an upgrade (Use your base from a calendar or a script).