Architecture & Systems
Library Release Versioning
Versioned releases and a changelog let you tie any valuation back to a specific library build and behaviour set.
Mental model
A versioned library build is part of the evidence needed to reproduce a valuation.
The analytics library is packaged and released with version numbers that distinguish breaking, feature, and bugfix changes.
Tagged releases in Git and a changelog document what changed so users and auditors can match results to code versions.
Explore the mechanism
Which behavior changed, and can a past valuation be tied to the exact released library that produced it?
- 1.4.2 — bugfix: daycount edge-case
- 1.4.1 — bugfix: curve interpolation guard
- 1.4.0 — feature: new bootstrapping method
- 1.3.0 — feature: additional Greeks
- Version tags let you reproduce valuations precisely.
- A changelog is an audit narrative: what changed, and why results might differ.
- Major bumps should be rare and explicit, because they break downstream systems.
Does the release number communicate compatibility?
What to notice
Risk and trading systems depend on explicit library versions instead of floating on the current state of the main branch.
Where it appears
- publishing pricing-library releases
- communicating breaking API changes
- reproducing valuations against historical builds
Where the intuition breaks
What this view leaves out
- A version number communicates intended compatibility only when releases are immutable and teams consistently define and test the public API.
Where this concept sits
Follow the strongest prerequisites, applications, extensions, and contrasts.
Connections for Library Release Versioning
Release automation should occur only after the required validation gates pass.
Used byPricing Library Architecture (Instrument–Market–Model–Pricer)A production pricing library uses explicit releases so each valuation can be tied to a known implementation state.
Supported byGit Workflow and Protected MainA controlled branch and review workflow gives releases an auditable source-history boundary.
Supported byProduct and Pricer RegistryRegistry changes are part of the public behaviour of a pricing library and should be versioned.
Supported bySchema Migrations and Backward CompatibilitySchema compatibility policy must be coordinated with versioned software releases that read and write those schemas.
Release automation should occur only after the required validation gates pass.
Explore concept →