Stability and Support Policy

Last updated: July 19, 2026 Document type: Governance policy

For SDK users and operators: understand stability commitments, support expectations, and version support timelines.

This document outlines the stability commitments, support expectations, and versioning practices for britecore_sdk.

Version Policy

britecore_sdk follows Semantic Versioning:

Major version (e.g., 2.0.0) — Breaking API changes
Minor version (e.g., 1.1.0) — New features, backward compatible
Patch version (e.g., 1.0.1) — Bug fixes, backward compatible

Release Cycle

Maintenance Windows

Active releases (current major version) — Bug fixes, security patches, minor features
Previous major version — Critical security fixes only, for 12 months after new major release
Older versions — No support

Example:

1.x.y (Active)          ← Bug fixes, minor features, security patches
0.x.y (Pre-release)     ← No ongoing support commitment
older                   ← No support

Release Schedule

Patch releases — As needed (usually weekly for bug fixes)
Minor releases — Monthly or as features accumulate
Major releases — 6–12 months apart

Backward Compatibility Guarantee

Within a major version

✅ Guaranteed compatible:
Bug fixes
New optional parameters (with sensible defaults)
New helper functions or utilities
Performance improvements
Internal implementation changes
❌ Not guaranteed compatible:
Removing public functions or classes
Changing function signatures (parameters, return types)
Changing exception types or error messages
Changing behavior of existing functionality
Modifying __all__ exports significantly

Example

# ✅ OK in minor release (e.g., 1.0.0 → 1.1.0)
def get_policy(policy_id, include_details=False):  # New optional param
    ...

# ❌ NOT OK in minor release (breaking change)
def get_policy(policy_id: str) -> dict:  # Changed return type
    ...  # Must wait for 2.0.0

Breaking Change Policy

When breaking changes are necessary:

Major release only — Public API removals and signature changes ship in a major release.
Documentation — Release notes and relevant guide pages are updated for the new contract.
Migration guidance — Replacement usage is documented in the release notes.

Example Timeline

0.0  → Initial stable API contract

1.0  → Non-breaking additions and fixes

0.0  → Breaking API update with migration guidance

Python Version Support

Current Support Matrix

From pyproject.toml: requires-python = ">=3.11"

Actively tested — Python 3.11, 3.12, 3.13, 3.14 (all versions in CI matrix)
Minimum supported — Python 3.11
Drop schedule — When upstream reaches end-of-life

Version Bumps

When Python versions reach end-of-life, we may:

Drop support — In a new major release (e.g., when 3.11 reaches EOL in October 2027, drop in 2.0.0)
Announce — In release notes at least 2 releases ahead

Current EOL dates (Python):

3.11: October 2027
3.12: October 2028
3.13: October 2029
3.14: October 2030

Dependency Stability

Pinning

Dependencies are pinned to compatible ranges:

Core deps: package~=X.Y.Z (patch-compatible)
Optional deps: Same approach
Dev deps: Looser pinning for flexibility