Release model
This page describes how Breqwatr develops, tests, and ships releases, and what that means for the Breqwatr public cloud.
Breqwatr follows a continuous delivery approach with a roll-forward release model. Releases are automated and frequent, fixes ship in the next release rather than being back-ported, and Breqwatr applies each release to the public cloud itself. You never need to upgrade anything on your side.
Development process
- Bug fixes are prioritised over new features.
- Every commit is peer reviewed before it is merged.
- Every commit is automatically tested through continuous integration.
- Every commit is automatically deployed to staging environments.
- Changes are manually tested on staging before release.
- Every commit produces a shippable build.
- Public releases are automated and published at the push of a button.
- Releases are frequent, so each one carries a small, reviewable set of changes.
Security
Security is part of the development process rather than a separate step:
- Code review includes a security review of every change.
- Automated tests cover authentication and authorization.
- CI pipeline audit jobs fail the build if a third-party dependency has a known vulnerability.
- Third-party software is upgraded monthly.
- Static application security testing (SAST) runs against both backend and frontend code.
- Independent third parties carry out periodic black-box and white-box penetration tests.
Release cadence
Breqwatr uses calendar versioning (CalVer) in the form
YYYY.MM.N, where N counts the releases made within that month:
| Version | Meaning |
|---|---|
2026.10.1 |
First release in October 2026 |
2026.10.2 |
Second release in October 2026 |
2026.11.1 |
First release in November 2026 |
Releases are made no more than twice a month.
Roll forward, no back-ports
Fixes are delivered in the next release only. Breqwatr does not back-port fixes to older versions. Instead, the public cloud rolls forward: Breqwatr upgrades it to each new release, so it always runs the latest version.