M .conver/draft.txt → .conver/draft.txt

@@ -1,1 +1,1 @@ 
-4509+450B

M CHANGELOG.md → CHANGELOG.md

@@ -1,5 +1,9 @@ 
 ## Convergent Versioning — Changelog
 
+### v450-B (2026-06-11)
+
+- BREAKING: replaced "size" metadata dimension with "impact".
+
 ### v410-7 (2026-06-10)
 
 - BREAKING: Dependencies are no longer required to have a higher score than projects that use them.

A VERSIONING.md

@@ -0,0 +1,7 @@ 
+This project uses the Convergent Versioning system. 
+
+The version number is a 2-byte hexadecimal integer from 0x0000 to 0xFFFF, with the first three digits indicating the project _dependability score_ and the last digit encoding the version impact, compatibility, and purpose. 
+
+A version number compliant with Semantic Versioning can be derived from the project history, and will still be used if required by package managers or similar software.
+
+For more information, see the [Convergent Versioning specification](https://h3rald.com/conver).

M conver.md → conver.md

@@ -1,13 +1,12 @@ 
 ## Convergent Versioning (ConVer)
 
-
 The current version of this document is **v410-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 in hexadecimal notation, conveying:
 - its dependability score, expressed as a value between 0x000 and 0xFFF (first three digits).
-- metadata expressing the size of the changes delivered, if the release breaks compatibility, and/or includes new enhancements (last digit).
+- metadata expressing the expected upgrade impact, if the release breaks compatibility, and/or includes new enhancements (last digit).
 
 Based on its dependability score, a project should be immediately classifiable as belonging to one of the following stages: 
 
@@ -18,7 +17,7 @@ - _bedrock_
 
 Each stage is meant to progressively restrict the type of changes introduced in subsequent releases. 
 
-As an example, the version number `0x9B04` immediately conveys that the project is in its _consolidated_ state (very dependable) and the version introduced changes to up to 25% of its content, with no breaking changes and no new enhancements. Because of its stage, subsequent releases will never include breaking changes or affect more than 25% of its content, but may include new enhancements.
+As an example, the version number `0x9B04` immediately conveys that the project is in its _consolidated_ state (very dependable) and the version is expected to have medium upgrade impact, with no breaking changes and no new enhancements. Because of its stage, subsequent releases will never include breaking changes or have more than medium-level upgrade impact, but may include new enhancements.
 
 ### Motivation
 
@@ -97,18 +96,20 @@ #### Version Metadata
 
 The last hexadecimal digit of a version number (henceforth called "metadata nibble") SHALL encode metadata characterizing the release based on three distinct dimensions:
 
-- Size
+- Impact
 - Compatibility
 - Purpose
 
-##### Size
+##### Impact
+
+Impact identifies the expected upgrade impact of the new release. Each value of the metadata nibble expresses a possible impact level among the following:
 
-Size identifies the amount of changes compared to the total size of the project. Each value of the metadata nibble expresses a possible size among the following:
+- L (0-3) — Low impact.
+- M (4-7) — Medium impact.
+- H (8-B) — High impact.
+- C (C-F) — Critical impact.
 
-- S (0-3) — Up to 5% of the project content was changed. 
-- M (4-7) — Up to 25% of the project content was changed.
-- L (8-B) — Up to 50% of the project content was changed.
-- X (C-F) — Up to 100% of the project content was changed.
+Note that the level of impact does not necessarily imply a breaking change, it may also mean that if there were no breaking changes, a release may have a low to critical impact in order to fully take advantage of a new enhancement introduced or a new correction, such as a performance improvement.
 
 #### Compatibility
 
@@ -126,24 +127,24 @@ - Even values of the metadata nibble mean that the release focuses only maintenance work, performance, reliability improvements, and bug fixing.
 
 #### Summary
 
-| Value | Size | Compatibility | Purpose |
+| Value | Impact | Compatibility | Purpose |
 |:--|:--|:--|:--|
-| F | X | Breaking | Enhancement |
-| E | X | Breaking | Maintenance |
-| D | X | Preserving | Enhancement |
-| C | X | Preserving | Maintenance |
-| B | L | Breaking | Enhancement |
-| A | L | Breaking | Maintenance |
-| 9 | L | Preserving | Enhancement |
-| 8 | L | Preserving | Maintenance |
+| F | C | Breaking | Enhancement |
+| E | C | Breaking | Maintenance |
+| D | C | Preserving | Enhancement |
+| C | C | Preserving | Maintenance |
+| B | H | Breaking | Enhancement |
+| A | H | Breaking | Maintenance |
+| 9 | H | Preserving | Enhancement |
+| 8 | H | Preserving | Maintenance |
 | 7 | M | Breaking | Enhancement |
 | 6 | M | Breaking | Maintenance |
 | 5 | M | Preserving | Enhancement |
 | 4 | M | Preserving | Maintenance |
-| 3 | S | Breaking | Enhancement |
-| 2 | S | Breaking | Maintenance |
-| 1 | S | Preserving | Enhancement |
-| 0 | S | Preserving | Maintenance |
+| 3 | L | Breaking | Enhancement |
+| 2 | L | Breaking | Maintenance |
+| 1 | L | Preserving | Enhancement |
+| 0 | L | Preserving | Maintenance |
 
 #### Dependability Stages
 
@@ -157,7 +158,7 @@ ##### Prototype (000-400)
 
 Projects in this stage are typically highly unstable, immature, and/or incomplete. As a result, releases within this stage:
 
-- MAY be of any size.
+- MAY have any impact.
 - MAY include breaking changes.
 - MAY include new enhancements.
 
@@ -165,7 +166,7 @@ ##### 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 size S, M, or L, but not X.
+- MAY have a L, M, H impact, but not C.
 - MAY include breaking changes.
 - MAY include new enhancements.
 
@@ -173,7 +174,7 @@ ##### 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 size S or M, but not L or X.
+- MAY have a L or M impact, but not H or C.
 - MUST NOT include breaking changes.
 - MAY include new enhancements.
 
@@ -181,7 +182,7 @@ ##### 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 size S but not M, L, or X.
+- MAY only have a S impact, not M, L, or C.
 - MUST NOT include breaking changes.
 - MUST NOT include new enhancements.
 
@@ -198,11 +199,11 @@ In this case, a ConVer release MUST be formatted as follows:
 
 "v" followed by the conversion of the dependability score into exactly four decimal digits, followed by "-", followed by metadata expressed via three-letters.
 
-- The first letter of the metadata identifies the size, and MUST be one of: S, M, L, or X.
+- The first letter of the metadata identifies the impact, and MUST be one of: L, M, H, or C.
 - The second letter identifies the compatibility, and MUST be either B (breaking) or P (preserving).
 - 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**.
+For example, **v13B-F** MAY be represented as **v0315-CBE**.
 
 #### Converting a ConVer release to SemVer