Release Process

Release Inputs

A release usually includes:

built and pushed container images
updated documentation
release notes
optional migration service changes
optional client changes

The optimized build architecture distinguishes between version-specific payload images, shared architecture-specific runtime images and final user-facing component images. Payload and runtime images are build dependencies; final images remain the images consumed by normal deployments.

Suggested Release Steps

Ensure the repository builds cleanly and the wiki tests pass.
Verify Server, Client and Firebird payload image availability.
Verify Server and GUI runtime images for the target architectures.
Verify Server, Admin, Client and mRomexis images for the target architectures.
Verify Migration Service and Control Agent images when affected.
Verify multiarch manifests.
Test Docker Compose startup.
Test database initialization.
Test migration service startup.
Create release notes.
Publish Gitea release.
Verify Gitea packages.

Image Layers to Verify

Layer	Images	Purpose
Payload	`romexis-payload`, `romexis-client-payload`, `romexis-firebird-payload`	Version-specific installer/database content
Runtime	`romexis-base-jre`, `romexis-gui-runtime`	Reusable architecture-specific dependencies
Final	`romexis-server`, `romexis-admin`, `romexis-client`, `romexis-mromexis-app`	Deployable Romexis components
Services	`romexis-migration-service`, `romexis-control-agent`	Independent supporting services

Image Verification

docker pull gitea.buchhorster.de/planmeca/romexis-server:<version>-amd64
docker pull gitea.buchhorster.de/planmeca/romexis-server:<version>

Inspect:

docker manifest inspect gitea.buchhorster.de/planmeca/romexis-server:<version>

The public multiarch tag is published only after the required architecture-specific staging images have completed successfully. Drone uses commit-specific ci-<commit>-... staging tags and creates the public manifest at the end of the pipeline, so the previous public manifest remains pullable during a running build.

Release Notes Should Mention

new features
migration service changes
database backend changes
breaking changes
required environment variable changes
known limitations

Changes that only affect internal payload/runtime build layers normally do not require deployment changes as long as the public final image names, tags and runtime interfaces remain compatible.

Gitea Areas

Use Gitea as follows:

Area	Purpose
Code	Source code and Dockerfiles
Releases	Human-readable versioned release notes
Packages	Published payload, runtime and final container images
Wiki	Operational and developer documentation
Issues	Bugs, feature requests and planning