Warning

🚧 Work in Progress: This page is currently under construction. Content may be incomplete or subject to change. To contribute, see the contribution guide.

Versioning Policy

---

Semantic versioning

All systems and libraries maintained by the Technology department follow Semantic Versioning: MAJOR.MINOR.PATCH

Part	When to increment	Example
MAJOR	Breaking changes — incompatible API or behavior change	1.x.x → 2.0.0
MINOR	New backward-compatible functionality	1.2.x → 1.3.0
PATCH	Backward-compatible bug fixes	1.2.3 → 1.2.4

---

Git tags

Every production release must be tagged in Git:

# Create an annotated tag
git tag -a v1.3.0 -m "Release v1.3.0: add capital call automation"
 
# Push the tag
git push origin v1.3.0

Tag naming convention: vMAJOR.MINOR.PATCH — always prefixed with v.

---

Changelog

Every system must maintain a changelog.md file using the Keep a Changelog format.

See the release notes template.

Rules:

• Add an entry for every release before merging to main
• The [Unreleased] section tracks changes not yet released
• Include breaking changes prominently

---

API versioning

For internal APIs, see REST Standards > Versioning.