Status: DraftCreated: 2026-06-08Comments: All aspects of this proposal are open for debate, particularly release cadence and support window duration.
Abstract
This RFC proposes a date-based API versioning strategy for Polar with the following characteristics:- Version lifecycle: 3 versions maintained with ~9-month support window — open for discussion
- Release cadence: Quarterly (January, April, July, October) — open for discussion
- Change policy: Strict freeze on Current and Deprecated versions; all contract changes through Next version
- Version naming:
YYYY-MMformat (e.g.,2026-01,2026-04) - Versioning mechanism:
Polar-Versionheader, defaulting to Current version
Motivation
Problems with Current Approach
Currently, Polar lacks a formal API versioning strategy. Our current approach is “best-effort”, where we try to limit breaking changes and maintain backward compatibility, but we have no guarantees or clear policies. This leads to several issues:- No strong guarantees for consumers about stability and support duration
- Deprecated fields and endpoints accumulate over time, increasing technical debt
- SDK versioning is inconsistent and often lags behind API changes
Desired Outcomes
Our goal is to implement a robust API versioning strategy that provides clear guarantees to consumers, enables disciplined API evolution, and reduces technical debt; while maintaining a fast-paced and innovative development process.Proposal
Release Schedule
Releases occur on a quarterly cadence during the first week of each quarter (January, April, July, October). The release is calendar-driven: it happens on the scheduled date regardless of feature completion. Incomplete work is deferred to the Next version.Version Lifecycle
Exactly 3 versions are maintained at any time:State Transitions
On each release:- N-1 is removed
- N becomes N-1 and is deprecated
- The Next version becomes N and is the new default. It is frozen for contract changes.
- A new Next version is created for ongoing development
Timeline Example
- ~3 months: Next (development phase, accepts all changes)
- ~3 months: Current (frozen, default version)
- ~3 months: Deprecated (frozen, removal pending)
- Total: ~9 months of support
If this is seen as too aggressive, we can consider a longer support window
(e.g., 12 months) by maintaining 4 versions instead of 3. See Appendix for
timeline examples.
Change Policy
Strict Freeze Rule
Deprecated and Current versions are completely frozen for contract changes.| Change Type | Deprecated | Current | Next |
|---|---|---|---|
| Add endpoint | ❌ | ❌ | ✅ |
| Remove endpoint | ❌ | ❌ | ✅ |
| Modify schema (add/remove/change fields) | ❌ | ❌ | ✅ |
| Change input/output format | ❌ | ❌ | ✅ |
| Bug fixes | ✅ | ✅ | ✅ |
| Performance improvements | ✅ | ✅ | ✅ |
| Internal implementation changes | ✅ | ✅ | ✅ |
Development Flow
- All contract changes are developed against the Next version
- When released, Next becomes Current and is frozen
- New contract changes target the new Next version
- Bug fixes can be applied to any maintained version
Version Increment
The version always increments on schedule, even if no contract changes have been made in that quarter. Rationale: Maintaining a regular cadence with predictable version numbers simplifies planning and avoids gaps in the version sequence.Removal Policy
Deprecated versions are removed on the next release date (hard cutoff).Version Naming
API versions use theYYYY-MM format representing the quarter of release:
Versioning Mechanism
Request Header
Clients specify the API version using a custom header:Default Behavior
When thePolar-Version header is omitted, requests are routed to the Current version.
SDK Strategy
The SDK will support the three supported versions at any time, through submodules. For example:Versioning strategy
- Bug fixes, performance improvements to the generated code: Patch version
- Added features, updates to the Next API version (models or endpoints): Minor version
- API version cycle: Major version. Since we’re removing a version, it’s a breaking change — users will need to change their import.
Implementation
Backend: Header-based routing POC
We introduce a newversion decorator to put on top of routes. By default, without the decorator, the route is available on all versions. If the decorator is used, the route is only available on the specified version(s). A more specific version takes precedence over a more general one.
Custom routing classes will then take care to create sub-FastAPI apps that expose the right endpoints and schemas for each version. The main app will route requests to the appropriate sub-app based on the Polar-Version header.
Usage
POC Implementation
Testing
We should have tests that lock the schema for N-1 and N versions to ensure no contract changes are allowed. If a change is attempted, the test should fail, indicating that the change must be made in the Next version instead.Documentation
- Version selector: Allow users to view docs for each maintained version
- Version indicators: Clearly mark deprecated versions in documentation
- Changelog: Maintain per-version changelog
- Migration guides: Provide guides for migrating between versions
Monitoring
We should track adoption of each version and monitor for errors. After one or two release cycles, we can evaluate if the cadence and support window are working as intended or if adjustments are needed.Rollout Plan
ASAP
- Start to tag API version in OpenAPI file.
- Continue to work as we do today, i.e. “best-effort” backward compatibility
Before September 2026
- Implement the API versioning logic in the server
- Have the SDK working as described in SDK Strategy
October 2026
- Freeze the API as it is under the version
2026-10 - Start the cycles by setting up the version
2027-01and start to work on this version only - Release the SDK with those two versions

