[Feature] An end-of-life and support-period policy (EL.01) #551

New issue

Closed

opened 2026-07-22 13:43:30 +00:00 by brenno · 0 comments

brenno commented

2026-07-22 13:43:30 +00:00

Owner

Grepping the whole repository for end-of-life, support period or discontinuation returns nothing. Not in SECURITY.md, not in README.md, not in docs/. It is the one row of the light-weight attestation checklist (#549) with no material behind it at all.

What EL.01 asks. From proposals/template-lite.md in orcwg/cra-attestations: the discontinuation of support for the project, parts of it, or specific versions of it should be communicated adequately, and the project should have a policy for that. The mapping table ties it to Annex VII.4 (support period) and to Article 13.3 — a manufacturer choosing dependencies wants to know whether the thing will still be maintained.

Why it matters here specifically, and not as paperwork. SECURITY.md promises a first response in 5 working days, an assessment in 10 and a fix in 90, and tool/check_service_norms.dart measures it. Those terms describe what happens while the project is alive. Nothing describes the other end. Someone building on OciDeck today has no way to tell whether a quiet month means busy or finished — and that is exactly what an outsider reads first.

What it should say, honestly. The project has no releases and no versions to support, so a support-period table would be theatre. What can be said is true and useful:

What "supported" means now — main is the supported version, there is nothing else, and a fix lands there and nowhere else.
What discontinuation would look like — a notice in README.md and SECURITY.md, an entry in CHANGELOG.md, and the tracker set to read-only rather than left to rot. Say how much notice, and say it in a period that can actually be honoured by one maintainer.
What happens to reports after that — an unmaintained project that still accepts vulnerability reports is worse than one that says it does not.
Archiving over deletion. The source stays available under its licence; anyone may fork. That is the real guarantee, and it is stronger than a support window.

Where it lives. A section in SECURITY.md if it stays short, otherwise its own docs/ file — and then it needs registering (pubspec assets, a reader tile in settings_dialog_docs.dart, a title in 31 languages), or docs_registration_test reddens make check.

Ties to #520: once there are releases, this policy gains a version dimension it does not have yet.

Grepping the whole repository for end-of-life, support period or discontinuation returns nothing. Not in `SECURITY.md`, not in `README.md`, not in `docs/`. It is the one row of the light-weight attestation checklist (#549) with no material behind it at all. **What EL.01 asks.** From `proposals/template-lite.md` in [orcwg/cra-attestations](https://github.com/orcwg/cra-attestations): the discontinuation of support for the project, parts of it, or specific versions of it should be communicated adequately, and the project should have a policy for that. The mapping table ties it to Annex VII.4 (support period) and to Article 13.3 — a manufacturer choosing dependencies wants to know whether the thing will still be maintained. **Why it matters here specifically, and not as paperwork.** `SECURITY.md` promises a first response in 5 working days, an assessment in 10 and a fix in 90, and `tool/check_service_norms.dart` measures it. Those terms describe what happens while the project is alive. Nothing describes the other end. Someone building on OciDeck today has no way to tell whether a quiet month means busy or finished — and that is exactly what an outsider reads first. **What it should say, honestly.** The project has no releases and no versions to support, so a support-period table would be theatre. What *can* be said is true and useful: - **What "supported" means now** — `main` is the supported version, there is nothing else, and a fix lands there and nowhere else. - **What discontinuation would look like** — a notice in `README.md` and `SECURITY.md`, an entry in `CHANGELOG.md`, and the tracker set to read-only rather than left to rot. Say how much notice, and say it in a period that can actually be honoured by one maintainer. - **What happens to reports after that** — an unmaintained project that still accepts vulnerability reports is worse than one that says it does not. - **Archiving over deletion.** The source stays available under its licence; anyone may fork. That is the real guarantee, and it is stronger than a support window. **Where it lives.** A section in `SECURITY.md` if it stays short, otherwise its own `docs/` file — and then it needs registering (pubspec assets, a reader tile in `settings_dialog_docs.dart`, a title in 31 languages), or `docs_registration_test` reddens `make check`. Ties to #520: once there *are* releases, this policy gains a version dimension it does not have yet.

brenno added the

triage

enhancement

docs

labels

2026-07-22 13:43:30 +00:00

brenno referenced this issue

2026-07-22 13:44:35 +00:00

[Feature] Machine-readable project metadata, so a third party can attest without asking #555

brenno referenced this issue from a commit

2026-07-22 15:40:44 +00:00

docs(security): zeg wat er gebeurt als dit project stopt, en wat je kunt volgen