M CHANGELOG.md → CHANGELOG.md

@@ -7,6 +7,7 @@ - Moved Changelog to a separate file.
 - BREAKING: Renamed all dimensions tracked in metadata and in particular changed _experimentation_ with _purpose_.
 - BREAKING: Renamed _established_ stage to _consolidated_.
 - Formalized an exact conversion from ConVer to SemVer.
+- Added section on dependency management.
 
 ### v300-5 (2026-06-07)
 

M conver.md → conver.md

@@ -7,7 +7,7 @@ ### Summary
 
 Given a project that aims to achieve the highest level of feature-completeness, maturity, and stability (collectively identified as _dependability_), its releases should be expressed using a single integer number of two bytes expressed in hexadecimal notation, conveying:
 - its dependability score, expressed as a value between 0x000 and 0xFFF (first three digits).
-- metadata expressing the magnitude of the changes delivered, and if the release includes breaking changes and/or experimental content, encoded in the last digit.
+- metadata expressing the size of the changes delivered, and if the release breaks compatibility and/or includes new enhancements, encoded in the last digit.
 
 Based on its dependability score, a project should be immediately classifiable as belonging to one of the following stages: _prototype_, _operational_, _consolidated_, and _bedrock_. Each stage is meant to progressively restrict the type of changes introduced in each release. 
 
@@ -154,15 +154,15 @@ ##### Operational (401-800)
 
 Projects in this stage are typically usable in production, although they MAY still improve substantially in terms of completeness, maturity, and stability. As a result, releases within this stage:
 
-- MAY be or magnitude S, M, or L, but not X.
+- MAY be or size S, M, or L, but not X.
 - MAY include breaking changes.
 - MAY include new enhancements.
 
-##### Established (801-C00)
+##### Consolidated (801-C00)
 
 Projects in this stage are typically regarded as reasonably complete, mature and/or stable, although they may still improve to achieve a higher degree of dependability. As a result, releases within this stage:
 
-- MAY be of magnitude S or M, but not L or X.
+- MAY be of size S or M, but not L or X.
 - MUST NOT include breaking changes.
 - MAY include new enhancements.
 
@@ -170,13 +170,20 @@ ##### Bedrock (C01-1000)
 
 Projects in this stage are typically regarded as complete, mature, and/or stable. As a result, releases within this stage:
 
-- MAY be of magnitude S but not M, L, or X.
+- MAY be of size S but not M, L, or X.
 - MUST NOT include breaking changes.
 - MUST NOT include new enhancements.
 
 Note that a score of 1000 MAY NOT be represented by Convergent Versioning, as it MAY NOT be reached.
 
-#### Alternative Decimal Format
+### Dependency Management
+
+Assuming that two projects "A" and "B" both follow Convergent Versioning, if "B" depends on "A", then:
+
+- The dependability score of "A" MUST be higher than the one of "B".
+- "B" MUST be compatible exactly with a specific version of "A", unless "A" is in _consolidated_ or _bedrock_ stage, in which case "B" MAY be compatible with any version of "A" with a score of 801 or higher (and therefore at least in _consolidated_ stage).
+
+### Alternative Decimal Format
 
 In cases when a the canonical format is deemed inconvenient or too cryptic for end users, an alternative decimal format MAY be used. 
 In this case, a ConVer release MUST be formatted as follows:
@@ -189,7 +196,7 @@ - The third letter identifies the purpose, and MUST be either E (enhancement) or M (maintenance).
 
 For example, **v13B-F** MAY be represented as **v0315-XBE**.
 
-#### Converting a ConVer release to SemVer
+### Converting a ConVer release to SemVer
 
 In situations where a SemVer like version is expected, such as in formats used by package managers and similar, a ConVer release MAY be converted into the corresponding SemVer-compliant release provides that the entire history project releases is known.