searches the current version of every section · esc to close

Viewing this section as of v0.1.47 (tagged 2026-04-18). Go to current →
00-Meta/04-Version-Control.md← v0.1.46v0.1.48 →

04 Version Control

In this section, the meaning and handling of the version of the standard are defined.

04.01 Version Number

The version number of the standard and each section of the standard use the format MAJOR.MINOR.PATCH. Notice this is not the standard semantic versioning.

  1. MAJOR version number is the released stable version of the standard. Each MAJOR bump is a release of a stable version, which is a closure of a set of proposed changes to the standard. Each MAJOR bump resets the MINOR version number to zero and increases the MAJOR version number by one. One can refer to a stable version of the standard by the MAJOR version number. For example, Manifold Standard Version 1 refers to Version 1.0.0 of the standard.
  2. MINOR version numbers are used for proposed changes for the next stable version of the standard. Each MINOR bump is a closure of a set of section changes to the standard, with each change labeled with a PATCH version number. Each MINOR bump resets the PATCH version number to zero and increases the MINOR version number by one.
  3. PATCH version numbers are used for proposed changes for the next stable version of one section of the standard. A PATCH bump of the standard is performed when a section of the standard is changed. This section is also marked with the full version number it was last changed. This mark can be referred to as the version number of this section.

04.02 Breaking Changes

A breaking change is a change that either:

  1. Makes the data format not backward compatible, or
  2. Alters the relationship between the data and the reconstructed space in a non-compatible way. This includes changes of default behaviors.

It is RECOMMENDED that stable releases of the standard do not introduce breaking changes. The version number does not imply whether changes are breaking or non-breaking. If a breaking change is included in a stable release, an attachment describing migration from the previous version to the current version MUST be provided in Section 90 of the release.

04.03 Notes on Implementation

  1. Closure is an event of obtaining and confirming the consensus of the Manifold Standard Editing Committee. The Manifold Standard Editing Committee is the maintenance team for the Manifold Standard before version 1.0.0. Each closure MUST ends with a version number bump and a tag of the version to the Git repository.
  2. If a change in one section requires edits in another section, and if the changes have a clear logical order, each edit SHOULD be followed by a PATCH bump. If term changes, typo changes, or convention changes occur in multiple sections, changes to multiple sections MAY be merged into one PATCH bump. If there is a set of inseparable changes across multiple sections, these changes MAY be merged into one PATCH bump.
  3. A section of the standard is defined as one markdown file.

04.04 Implementation of Referencing

  1. Each release of the stable version contains an archive action, for which the released standard MUST be uploaded to durable storage, obtaining the URI for referencing the standard of the particular stable version.
  2. Each proposed version can be referred to using the git tag.
  3. MINOR/PATCH version of the standard MUST NOT be cited as normative in external integrations.

04.05 Errata for Stable Releases

Each post-release erratum of the stable release version is additional documentation called amendments to the stable release version, specifying fixes to the standard of the stable release version. The amended stable release version of the standard is referred to using the version number MAJOR.0.0.ERRATA. It is RECOMMENDED not to issue an erratum for the stable release version unless critical mistakes are made. The amendments MUST be uploaded to durable storage, obtaining the URI for referencing.

04.06 Expiration of This Section

The version numbering, meaning, and handling described in this section are for versions before version 1.0.0. At version 1.0.0, versioning and change control transfer to the governance model that is defined at that time. The governance model after version 1.0.0 may or may not follow this handling of version numbers.