Skip to content

docs: define versioning, deprecation, and support policy #46

Description

@devops-thiago

Problem Statement

SECURITY.md lists only "latest" as supported, and there is no documented versioning or deprecation policy. For a project asking operators to deploy and upgrade in place, the compatibility promise (config keys, image names, schema, webhook behavior) and how breaking changes are signaled need to be explicit.

Proposed Solution

Document a versioning and support policy: semantic-versioning commitments, what counts as the public contract (env/thrillhousebot.* config, image tags, DB schema, webhook behavior), a deprecation process, and which versions receive security fixes. Update SECURITY.md accordingly.

Alternatives Considered

  • Leave it implicit — risky for operators relying on stability.

Priority

Nice to have

Code of Conduct

  • I have searched for existing issues and this is not a duplicate.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions