Skip to content

API versioning contract is inconsistent: version edge cases not exercised across controllers #1243

Description

@nanaf6203-bit

Context

DEFAULT_API_VERSION = v2, v1 is deprecated with sunsetDate 2026-12-31, v2 released 2026-04. Controllers mostly have no per-version DTO differences, and no endpoints intentionally diverge (v1 vs v2) apart from the versioning module's own examples.

Problem

Deprecation of v1 is implied but no real v1 responses are frozen; consumers get v2-shaped payloads from a 'v1' that was never pinned, making the sunset date aspirational. Without per-version fixtures, backward-compatibility.service has little to protect.

Proposed approach

Inventory endpoints and choose a versioning policy (URI vs header) to document in docs/API_VERSIONING.md; freeze v1 response examples (Swagger examples/snapshot tests) and add drift detection for v1 vs v2.

Acceptance criteria

  • v1 output for key endpoints is snapshot-pinned and CI detects drift.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Stellar WaveIssues in the Stellar wave programapiAPI relateddocstech-debtTechnical debt

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions