{ "format": "cyberplanetary/standard-release/1", "designator": "CP 0000", "title": "How these standards are numbered, versioned and retired", "kind": "rules", "publisher": "Cyberplanetary", "version": "1.0.0", "released": "2026-10-04T11:01:58Z", "canonical_url": "https://cyberplanetary.org/standards/cp-0000/1.0.0/cp-0000-1.0.0.md", "canonical_sha256": "f35e08335c4fa78334ed9d8de30eddeca6a6e8da271190d90705def6a7c42aa6", "release_digest": "de616b3691f922d77af69e13a79524a960a5785507ec1e18046bb021ed24b3b5", "change_summary": "Initial standards-series rules.", "source_manifest": { "format": "publication-series-manager/document/1", "work": "CP 0000", "parts": [ { "id": "contents", "role": "front", "generated": "contents" }, { "id": "scope", "role": "clause", "file": "scope.md" }, { "id": "designators", "role": "clause", "file": "designators.md" }, { "id": "versions", "role": "clause", "file": "versions.md" }, { "id": "status", "role": "clause", "file": "status.md" }, { "id": "using", "role": "clause", "file": "using.md" } ], "references": [] }, "document": { "format": "cyberplanetary/resolved-document/1", "work": "CP 0000", "parts": [ { "id": "part-contents", "content_markdown": "## Contents\n\n- [1 Scope](#clause-1)\n- [2 Designators and citation](#clause-2)\n - [2.1 Works and numbers](#clause-2-1)\n - [2.2 Versions](#clause-2-2)\n - [2.3 Citing](#clause-2-3)\n- [3 What a version number means](#clause-3)\n - [3.1 Reading a version](#clause-3-1)\n - [3.2 Initial development and pre-releases](#clause-3-2)\n - [3.3 Mistakes](#clause-3-3)\n- [4 Status](#clause-4)\n - [4.1 Status of a version](#clause-4-1)\n - [4.2 Status of a work](#clause-4-2)\n- [5 Relying on these standards](#clause-5)\n - [5.1 What does not change](#clause-5-1)\n - [5.2 What does change](#clause-5-2)\n - [5.3 Checking a digest](#clause-5-3)\n - [5.4 What the digests prove](#clause-5-4)\n\n" }, { "id": "clause-1", "content_markdown": "## 1 Scope\n\nThis document explains how Cyberplanetary numbers, edits, publishes and retires its documents, so that anyone who cites or implements one of them can tell exactly which text is meant and whether it is still in force.\n\nIt does not specify the content of any other standard. It is itself a standard of the series and follows its own rules.\n\n" }, { "id": "clause-2", "content_markdown": "## 2 Designators and citation\n\n" }, { "id": "clause-2-1", "content_markdown": "### 2.1 Works and numbers\n\nEvery document Cyberplanetary publishes is a *work* with a designator of the form `CP NNNN`, for example `CP 0007`. The number is assigned once, in sequence, and has no meaning: it does not encode the subject, the kind of document, the date or the maturity. A number is never reused, including for a work that was never released or has been withdrawn.\n\nA number is either a single document or a family of parts, never both. The parts of a family are written `CP NNNN-P`, for example `CP 0009-2`. They share the number and the family title; each part has its own versions. A bare family designator such as `CP 0009` means all of its parts.\n\n" }, { "id": "clause-2-2", "content_markdown": "### 2.2 Versions\n\nEach time the text of a work changes, a new *version* is released. Versions follow Semantic Versioning 2.0.0: `MAJOR.MINOR.PATCH`, for example `2.1.0`, with an optional pre-release tag such as `2.1.0-rc.1`. A released version is never altered. A version is written `CP NNNN v2.1.0`.\n\n" }, { "id": "clause-2-3", "content_markdown": "### 2.3 Citing\n\nTo mean exactly one text, cite the version: `CP 0007 v2.1.0`. Use this form for any claim of conformity, for a dependency, and in the normative references of other documents.\n\nTo mean the latest stable version whenever the reader reads it, cite the work: `CP 0007`. This is an undated reference; the text it points to can change.\n\nA dependency can also give a range. `CP 0007 ^2.1.0` means any released stable version from 2.1.0 up to, but not including, 3.0.0. The `^` and `~` notations come from npm, not from the Semantic Versioning specification.\n\nThe full form adds the release date and the title: `CP 0007 v2.1.0 (2026-11-02) \"Title\"`.\n\n" }, { "id": "clause-3", "content_markdown": "## 3 What a version number means\n\n" }, { "id": "clause-3-1", "content_markdown": "### 3.1 Reading a version\n\nA version is `MAJOR.MINOR.PATCH`. The classes describe the effect on an implementation that conformed to the previous version.\n\n- **Major**: a change a conforming implementation must respond to. This includes a new or tightened requirement, a removed feature or permission, and a changed term that affects requirements. A major version after `1.0.0` carries a migration note saying what an implementer must change.\n- **Minor**: a change an implementation may ignore without losing conformance. This includes a new permission, recommendation, optional capability or informative material, and a new term that changes no existing one.\n- **Patch**: no effect on any conforming implementation. This includes typographical errors, clarifications that keep the meaning, fixed links, and regenerated metadata.\n\nWhen a change could be classed two ways, the higher class is used. The class is the publisher's judgment, not something a tool can verify.\n\n" }, { "id": "clause-3-2", "content_markdown": "### 3.2 Initial development and pre-releases\n\nWhile the major version is 0, the document is in initial development: anything may change at any time, and no compatibility is promised. Version `1.0.0` is the point at which the publisher promises that later versions will follow the classes above.\n\nA version with a tag, such as `1.0.0-rc.1`, is a pre-release. It is published for review, ranks below the release it leads to, and is never the current version.\n\n" }, { "id": "clause-3-3", "content_markdown": "### 3.3 Mistakes\n\nThere are no errata and a released version is never edited. Any correction is a new patch version. A version that was classed wrongly is replaced by a correct version and then marked withdrawn, with a note saying why and which version to use.\n\n" }, { "id": "clause-4", "content_markdown": "## 4 Status\n\n" }, { "id": "clause-4-1", "content_markdown": "### 4.1 Status of a version\n\n- *pre-release*: published for review; not a stable version.\n- *current*: the latest stable version of an active work. There is exactly one.\n- *superseded*: replaced by a later version or work; kept for reference. A note may say how long, if at all, it receives fixes.\n- *withdrawn*: the publisher no longer endorses it; kept for reference, with a note saying why.\n\n" }, { "id": "clause-4-2", "content_markdown": "### 4.2 Status of a work\n\nA work is *reserved* (numbered, nothing released), *active*, *superseded* by another work, or *withdrawn*.\n\nStatus is not part of a released text, because it changes after release. It is recorded in the catalogue, and a notice may be added when a text is displayed.\n\n" }, { "id": "clause-5", "content_markdown": "## 5 Relying on these standards\n\n" }, { "id": "clause-5-1", "content_markdown": "### 5.1 What does not change\n\nThe text of a released version does not change, and its address does not change or disappear. A withdrawn or superseded version stays available with a notice. The catalogue records a digest of every released file, so a copy can be checked.\n\n" }, { "id": "clause-5-2", "content_markdown": "### 5.2 What does change\n\nStatus, and the meaning of an undated citation, change when new versions are released. To depend on a specific text, cite a version as described in [subclause 2.3](#clause-2-3). A dependency on a range accepts every stable version inside the range.\n\n" }, { "id": "clause-5-3", "content_markdown": "### 5.3 Checking a digest\n\nThe digest of a file is its SHA-256: run `sha256sum` on the file and compare.\n\nEach version also has a chain digest, the SHA-256 of one line of text:\n\n```\n v \n```\n\nFor example, for a first version:\n\n```\nprintf '%s' 'CP 0007 v1.0.0 2026-11-02T14:03:00Z -' | sha256sum\n```\n\nUse `printf '%s'`, not `echo`: `echo` adds a newline and gives a different digest. The chain digest of the latest version of a work is its head digest, published in the catalogue. Record the head digest you last saw and compare it with the catalogue the next time you look: a change to any earlier version, or the removal of one, shows as a difference.\n\n" }, { "id": "clause-5-4", "content_markdown": "### 5.4 What the digests prove\n\nThey prove that bytes are unchanged and that the history has not been rewritten behind a head digest you recorded. They do not prove who published a version or that it is correct. Removing the newest version is visible only by comparing with a head digest recorded elsewhere.\n" } ], "canonical_markdown": "# How these standards are numbered, versioned and retired\n\n**CP 0000 v1.0.0 (2026-10-04T11:01:58Z)**\n\n- Publisher: Cyberplanetary\n- Kind: rules\n- Change class: first stable release\n- Cite as: CP 0000 v1.0.0 (this version); CP 0000 (always the latest stable version)\n\nSummary of changes: Initial standards-series rules.\n\nThe status of a version (current, superseded, withdrawn) is not part of this text, because it changes after release. See https://cyberplanetary.org/standards/cp-0000/.\n\nCyberplanetary standard. Distributed with the project under AGPL-3.0-only; see the canonical repository LICENSE. Standard status is recorded in the series catalogue.\n\n\n\n## Contents\n\n- [1 Scope](#clause-1)\n- [2 Designators and citation](#clause-2)\n - [2.1 Works and numbers](#clause-2-1)\n - [2.2 Versions](#clause-2-2)\n - [2.3 Citing](#clause-2-3)\n- [3 What a version number means](#clause-3)\n - [3.1 Reading a version](#clause-3-1)\n - [3.2 Initial development and pre-releases](#clause-3-2)\n - [3.3 Mistakes](#clause-3-3)\n- [4 Status](#clause-4)\n - [4.1 Status of a version](#clause-4-1)\n - [4.2 Status of a work](#clause-4-2)\n- [5 Relying on these standards](#clause-5)\n - [5.1 What does not change](#clause-5-1)\n - [5.2 What does change](#clause-5-2)\n - [5.3 Checking a digest](#clause-5-3)\n - [5.4 What the digests prove](#clause-5-4)\n\n\n\n## 1 Scope\n\nThis document explains how Cyberplanetary numbers, edits, publishes and retires its documents, so that anyone who cites or implements one of them can tell exactly which text is meant and whether it is still in force.\n\nIt does not specify the content of any other standard. It is itself a standard of the series and follows its own rules.\n\n\n\n## 2 Designators and citation\n\n\n\n### 2.1 Works and numbers\n\nEvery document Cyberplanetary publishes is a *work* with a designator of the form `CP NNNN`, for example `CP 0007`. The number is assigned once, in sequence, and has no meaning: it does not encode the subject, the kind of document, the date or the maturity. A number is never reused, including for a work that was never released or has been withdrawn.\n\nA number is either a single document or a family of parts, never both. The parts of a family are written `CP NNNN-P`, for example `CP 0009-2`. They share the number and the family title; each part has its own versions. A bare family designator such as `CP 0009` means all of its parts.\n\n\n\n### 2.2 Versions\n\nEach time the text of a work changes, a new *version* is released. Versions follow Semantic Versioning 2.0.0: `MAJOR.MINOR.PATCH`, for example `2.1.0`, with an optional pre-release tag such as `2.1.0-rc.1`. A released version is never altered. A version is written `CP NNNN v2.1.0`.\n\n\n\n### 2.3 Citing\n\nTo mean exactly one text, cite the version: `CP 0007 v2.1.0`. Use this form for any claim of conformity, for a dependency, and in the normative references of other documents.\n\nTo mean the latest stable version whenever the reader reads it, cite the work: `CP 0007`. This is an undated reference; the text it points to can change.\n\nA dependency can also give a range. `CP 0007 ^2.1.0` means any released stable version from 2.1.0 up to, but not including, 3.0.0. The `^` and `~` notations come from npm, not from the Semantic Versioning specification.\n\nThe full form adds the release date and the title: `CP 0007 v2.1.0 (2026-11-02) \"Title\"`.\n\n\n\n## 3 What a version number means\n\n\n\n### 3.1 Reading a version\n\nA version is `MAJOR.MINOR.PATCH`. The classes describe the effect on an implementation that conformed to the previous version.\n\n- **Major**: a change a conforming implementation must respond to. This includes a new or tightened requirement, a removed feature or permission, and a changed term that affects requirements. A major version after `1.0.0` carries a migration note saying what an implementer must change.\n- **Minor**: a change an implementation may ignore without losing conformance. This includes a new permission, recommendation, optional capability or informative material, and a new term that changes no existing one.\n- **Patch**: no effect on any conforming implementation. This includes typographical errors, clarifications that keep the meaning, fixed links, and regenerated metadata.\n\nWhen a change could be classed two ways, the higher class is used. The class is the publisher's judgment, not something a tool can verify.\n\n\n\n### 3.2 Initial development and pre-releases\n\nWhile the major version is 0, the document is in initial development: anything may change at any time, and no compatibility is promised. Version `1.0.0` is the point at which the publisher promises that later versions will follow the classes above.\n\nA version with a tag, such as `1.0.0-rc.1`, is a pre-release. It is published for review, ranks below the release it leads to, and is never the current version.\n\n\n\n### 3.3 Mistakes\n\nThere are no errata and a released version is never edited. Any correction is a new patch version. A version that was classed wrongly is replaced by a correct version and then marked withdrawn, with a note saying why and which version to use.\n\n\n\n## 4 Status\n\n\n\n### 4.1 Status of a version\n\n- *pre-release*: published for review; not a stable version.\n- *current*: the latest stable version of an active work. There is exactly one.\n- *superseded*: replaced by a later version or work; kept for reference. A note may say how long, if at all, it receives fixes.\n- *withdrawn*: the publisher no longer endorses it; kept for reference, with a note saying why.\n\n\n\n### 4.2 Status of a work\n\nA work is *reserved* (numbered, nothing released), *active*, *superseded* by another work, or *withdrawn*.\n\nStatus is not part of a released text, because it changes after release. It is recorded in the catalogue, and a notice may be added when a text is displayed.\n\n\n\n## 5 Relying on these standards\n\n\n\n### 5.1 What does not change\n\nThe text of a released version does not change, and its address does not change or disappear. A withdrawn or superseded version stays available with a notice. The catalogue records a digest of every released file, so a copy can be checked.\n\n\n\n### 5.2 What does change\n\nStatus, and the meaning of an undated citation, change when new versions are released. To depend on a specific text, cite a version as described in [subclause 2.3](#clause-2-3). A dependency on a range accepts every stable version inside the range.\n\n\n\n### 5.3 Checking a digest\n\nThe digest of a file is its SHA-256: run `sha256sum` on the file and compare.\n\nEach version also has a chain digest, the SHA-256 of one line of text:\n\n```\n v \n```\n\nFor example, for a first version:\n\n```\nprintf '%s' 'CP 0007 v1.0.0 2026-11-02T14:03:00Z -' | sha256sum\n```\n\nUse `printf '%s'`, not `echo`: `echo` adds a newline and gives a different digest. The chain digest of the latest version of a work is its head digest, published in the catalogue. Record the head digest you last saw and compare it with the catalogue the next time you look: a change to any earlier version, or the removal of one, shows as a difference.\n\n\n\n### 5.4 What the digests prove\n\nThey prove that bytes are unchanged and that the history has not been rewritten behind a head digest you recorded. They do not prove who published a version or that it is correct. Removing the newest version is visible only by comparing with a head digest recorded elsewhere.\n" } }