Release

A release is a version of your app that you put out: with a version number, a label on GitHub and the files people can download. You do this on the Release page.

Version numbers

Coodoo keeps track of version numbers using semantic versioning: 1.4.2 means major version 1, feature version 4, fix version 2.

• After every goal, Coodoo bumps the number of each part that changed and writes what's new in CHANGELOG.md. This is on under Autopilot settings → Keep track of version numbers.
• The numbers are in .coodoo/versions.json, the only team memory file that does go into git.
• On the dashboard you see them under Components.

Changelog for users

CHANGELOG.md is technical. Next to it, Coodoo writes a changelog for the people who use your app with every new version: only what they notice, in plain language, grouped under New, Fixed and Improved.

• Pick the languages under Autopilot settings → Changelog for users. Dutch is the default. A language you add later gets an entry from the next version on; older versions can be filled in on the Changelog page.
• Each language has its own file: changelog/nl.md, changelog/en.md and so on, newest version first. The files go into the version commit.
• When users notice nothing in a version, for example with maintenance only, the entry has one neutral line.
• When writing fails, the version still goes ahead. Coodoo records the missing entry in .coodoo/versions.json.
• A release on GitHub uses this changelog as its release text: in Coodoo's language when your project has it, otherwise in the first language you picked.

One-time setup

The first time, click First, a one-time setup. You answer a few questions:

From which branch?

The branch you release from, usually main.

Where is it built?

• On this computer: free. Fill in the Build command, or click Fill in a suggestion to have Coodoo suggest one.
• On GitHub (Actions): GitHub builds it. Fill in the Workflow name (release.yml by default). The workflow has to be startable by hand (workflow_dispatch) and have a tag input.

Which files go into the release?

Patterns for the files that should be included, like dist/*.dmg or build/*.zip.

Advanced: variables for the build

Does the build need keys (for example to sign your app)? For each variable, pick a key from the Project vault or a Plain value.

Where can releases go?

Destination	What you need
GitHub, in this repository	Nothing extra
GitHub, in another repository	The Repository, and a token: My GitHub login in Coodoo or a token from the vault
Your own storage (S3)	Bucket, Region, optionally the Storage address (for Cloudflare R2, DigitalOcean Spaces or MinIO), a Folder in the bucket ({tag}/ by default) and the access keys from the vault

Releasing a version

1. Click Release a new version.
2. Which version will this be? Coodoo makes a suggestion based on what changed (recommended). Or choose yourself: Big change, New features, Fixes only, the Current version, or Enter it yourself.
3. Where to: pick the destination.
4. Click Release.

Coodoo then goes through: Check → Set version → Build → Version label on GitHub → Upload. Files first go to a draft release, which is only published once everything has succeeded.

Under Earlier releases you see what has already been released.

Note: A file that is already in a release is never replaced, and Coodoo never deletes anything. Want to redo a release? Release a new version.