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
Problem Statement
SECURITY.mdlists 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. UpdateSECURITY.mdaccordingly.Alternatives Considered
Priority
Nice to have
Code of Conduct