Release Tagging and Docker Images

This guide defines the release version and Git tag convention used when preparing Thalabus production Docker images.

Version source

Before creating a release tag, read ThalabusInterfaces/Data/Constants/ThalabusVersion.cs and use its Major, Minor, and Build values. The release version is:

<Major>.<Minor>.<Build>

For example, values 2, 6, and 6 produce version 2.6.6.

Branch and tag convention

Release procedure

Run these checks from the repository root:

git status --short --branch
git branch --show-current
git tag --sort=-version:refname

Confirm that the current branch is the intended release branch and that the version in ThalabusVersion.cs matches the tag to be created. Then create and verify the tag:

git tag v<Major>.<Minor>.<Build> HEAD
git show-ref --tags v<Major>.<Minor>.<Build>
git show --no-patch --format=fuller v<Major>.<Minor>.<Build>

After local verification, publish the tag when the production release is approved:

git push origin v<Major>.<Minor>.<Build>

Docker image build handoff

Build production images from the tagged commit so all images correspond to the same source version. Use the repository's Docker Compose or individual Dockerfiles as appropriate for the deployment:

git checkout v<Major>.<Minor>.<Build>
docker compose build

If a deployment uses selected images only, build those Compose services explicitly instead of building unrelated services. Apply the release tag to published image names according to the target registry's naming policy; the Git tag remains the authoritative source release label.

Example

For the main-rel-2.6.x branch with Major = 2, Minor = 6, and Build = 6:

Git tag:     v2.6.6
Git commit:  the release branch HEAD containing version 2.6.6
Docker build: performed from v2.6.6