Version Control & Release

The project uses Git as its version control system and is hosted on GitHub. The main branch is the default branch and serves as the single source of truth for production releases.

Commit Conventions

The project adopts Conventional Commits for commit messages. Compliance is enforced via a pre-commit hook managed by Husky: every commit attempt is validated against the Conventional Commits format before it is accepted.

Each commit may optionally include a service scope to explicitly associate the change with a specific microservice:

feat(documents): add medical report validator
fix(appointments): validate overlap edge case

Unscoped commits are also supported and are automatically resolved by changed file paths: if the modified files belong to one or more service directories, each affected service is considered for release.

Versioning & Release

The project follows Semantic Versioning. Releases are fully automated using Semantic Release, which analyzes commit messages to determine the next version number, generate the changelog, and publish the release. Each microservice is versioned independently: a change to, e.g., documents-service only bumps its own version, leaving other services unaffected.

Releases are triggered automatically on every push to main. Each service release produces:

• A Git tag in the format <service>-v<semver> (e.g. documents-v1.4.0).
• A GitHub Release with an auto-generated changelog, published at the Releases page.
• A Docker image pushed to GitHub Container Registry (GHCR) at ghcr.io/<owner>/<repo>/<service>:<version> and :<latest>.

The commons subproject participates in versioning but has no Docker publish target, as it is a shared library consumed by other services rather than a deployable unit.