generated: '2026-08-27'
method: searched
source: https://github.com/CodeWithCJ/SparkyFitness/releases
versioning:
  application: semver, tagged vMAJOR.MINOR.PATCH (currently v1.6.4)
  api: >-
    Partial path-based versioning. Most operations are unversioned under /api;
    nine resource families are served under /api/v2 alongside their unversioned
    predecessors. No version header, no negotiation, no stated default.
  policy_published: false
  note: >-
    info.description in the contract states the API "is subject to change
    without notice due to heavy development" and warns that improper direct use
    "may lead to data loss or corruption". That is the project's own stability
    posture, stated in the contract itself, and an integrator should read it as
    the versioning policy: there isn't one.
deprecation:
  policy_published: false
  sunset_header: false
  deprecation_header: false
  rfc8594: false
  deprecated_operations_in_spec: 0
  note: >-
    No operation in the 423-operation contract carries `deprecated: true`, no
    Sunset or Deprecation response header is documented or emitted, and there is
    no deprecation policy page. Old and v2 generations of the same resource run
    side by side with nothing marking either as going away. NO `Deprecation`
    pointer is emitted for this provider — there is no policy to point at.
  observed_breaking_change:
    change: >-
      POST /health-data changed from 400-on-any-record-failure to
      200-with-errors[]. Documented in the API reference as a "Breaking change
      note (v0.18+)" with migration guidance — a real, honest breaking-change
      notice, but a one-off in prose rather than a policy or a changelog
      convention.
    source: https://codewithcj.github.io/SparkyFitness/developer/api-reference
status_page:
  published: false
  note: >-
    There is none, and there cannot be a meaningful one: SparkyFitness is
    self-hosted, so availability is each operator's own. The application exposes
    its own health surface instead (a /health route family in the server) and a
    version endpoint pair, GET /version/current and GET /version/latest-github,
    which an operator can poll to see whether their deployment is behind the
    latest release. NO `StatusPage` pointer is emitted.
sla:
  published: false
  note: No SLA, no uptime commitment, no support tier. Community project.
support:
  channels:
    - type: chat
      url: https://discord.gg/vcnMT5cPEA
      note: Named in the README as the fastest route to help.
    - type: issues
      url: https://github.com/CodeWithCJ/SparkyFitness/issues
    - type: discussions
      url: https://github.com/CodeWithCJ/SparkyFitness/discussions
    - type: docs
      url: https://codewithcj.github.io/SparkyFitness/help-me
release_cadence:
  observed: every 1-3 weeks over the last three months
  latest: v1.6.4 on 2026-08-27
  channel: GitHub Releases + Docker Hub tags (latest and vX.Y.Z, published within minutes of each other)
maturity:
  repo_created: '2025-06-21'
  stars: 5653
  forks: 335
  open_issues: 129
  archived: false
  last_push: '2026-08-27'
  note: >-
    Actively developed — the repo was pushed and a release cut on the same day
    this profile was built.