How these standards are numbered, versioned and retired

CP 0000 v1.0.0 (2026-10-04T11:01:58Z)

• Publisher: Cyberplanetary
• Kind: rules
• Change class: first stable release
• Cite as: CP 0000 v1.0.0 (this version); CP 0000 (always the latest stable version)

Summary of changes: Initial standards-series rules.

The 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/.

Cyberplanetary standard. Distributed with the project under AGPL-3.0-only; see the canonical repository LICENSE. Standard status is recorded in the series catalogue.

Contents

• 1 Scope
• 2 Designators and citation
• 2.1 Works and numbers
• 2.2 Versions
• 2.3 Citing
• 3 What a version number means
• 3.1 Reading a version
• 3.2 Initial development and pre-releases
• 3.3 Mistakes
• 4 Status
• 4.1 Status of a version
• 4.2 Status of a work
• 5 Relying on these standards
• 5.1 What does not change
• 5.2 What does change
• 5.3 Checking a digest
• 5.4 What the digests prove

1 Scope

This 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.

It does not specify the content of any other standard. It is itself a standard of the series and follows its own rules.

2 Designators and citation

2.1 Works and numbers

Every 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.

A 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.

2.2 Versions

Each 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.

2.3 Citing

To 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.

To 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.

A 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.

The full form adds the release date and the title: CP 0007 v2.1.0 (2026-11-02) "Title".

3 What a version number means

3.1 Reading a version

A version is MAJOR.MINOR.PATCH. The classes describe the effect on an implementation that conformed to the previous version.

• 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.
• 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.
• Patch: no effect on any conforming implementation. This includes typographical errors, clarifications that keep the meaning, fixed links, and regenerated metadata.

When 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.

3.2 Initial development and pre-releases

While 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.

A 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.

3.3 Mistakes

There 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.

4 Status

4.1 Status of a version

• pre-release: published for review; not a stable version.
• current: the latest stable version of an active work. There is exactly one.
• superseded: replaced by a later version or work; kept for reference. A note may say how long, if at all, it receives fixes.
• withdrawn: the publisher no longer endorses it; kept for reference, with a note saying why.

4.2 Status of a work

A work is reserved (numbered, nothing released), active, superseded by another work, or withdrawn.

Status 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.

5 Relying on these standards

5.1 What does not change

The 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.

5.2 What does change

Status, 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. A dependency on a range accepts every stable version inside the range.

5.3 Checking a digest

The digest of a file is its SHA-256: run sha256sum on the file and compare.

Each version also has a chain digest, the SHA-256 of one line of text:

<designator> v<version> <release time> <file digest> <previous chain digest, or - for the first version>

For example, for a first version:

printf '%s' 'CP 0007 v1.0.0 2026-11-02T14:03:00Z <file digest> -' | sha256sum

Use 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.

5.4 What the digests prove

They 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.