Release Strategy¶

FHIR Frog uses four independently versioned release units.

Release Units¶

Unit	Repository	Tag Convention	Storage	Trigger
Codebase	`fhir-frog`	`v*` (e.g. `v1.2.0`)	GitLab Package Registry / Maven Central	Git tag
Skin	`fhir-frog-maven-skin`	`v*` (e.g. `v1.0.0`)	GitLab Package Registry	Git tag
Website	`fhir-frog-website`	N/A — deployed as `latest`	GitLab Pages	Push to main
Docker	`fhir-frog-runtime`	Image tag matches codebase version	GitLab Container Registry	Nightly (if changed)

Codebase Releases¶

Versioning is managed by jgitver from annotated Git tags:

# Create a release
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin v1.2.0

Commits on main after a tag produce X.Y.Z-SNAPSHOT versions
Tagged commits produce exact X.Y.Z versions
Snapshots deploy to GitLab Package Registry
Releases deploy to Maven Central (via OSSRH with GPG signing)

Codebase modules all share the same version: library, CLI, Maven plugin, Ant task, rendering, testplan, shorthand.

Skin Releases¶

The Maven site skin lives in a separate repository with its own jgitver setup. It changes rarely — only when site styling is updated.

The main project references the skin via ${skin.version} property in the parent pom.

Website Deployment¶

The MkDocs documentation site lives in its own repository and deploys automatically on every push to main as GitLab Pages.

Artifacts retained for 90 days
No numeric version — always latest

Docker Image¶

The Docker runtime image lives in its own repository with a nightly CI schedule that checks whether upstream artifacts (CLI fat JAR, website) have changed:

No changes → skip build
Changes detected → rebuild and push to registry.gitlab.com/fhirfrog/runtime

Image tags: - runtime:latest — always the most recent build - runtime:<version> — pinned to a specific codebase version

Registry: registry.gitlab.com/fhirfrog-runtime

Image labels record provenance: - org.fhirfrog-frog.codebase-version - org.fhirfrog-frog.codebase-digest - org.fhirfrog-frog.website-ref - org.fhirfrog-frog.built-at