-
Notifications
You must be signed in to change notification settings - Fork 0
guidelines git_specification versioning
Note
WorldVer currently adapted from RomVer. Feedback is welcome.
There is also a Conventional Commits specifiication made for Worldbuilding in the repo.
This is an adaptation of the RomVer format. Made specifically for worldbuilding
The Romantic Versioning specification was originally authored by Daniel V in 2015.
Creativity dump, i guess? Also inspired by other RPG's "Editions"/"Versions"
However:
- It SHOULD ease author or role player to stick to certain "snapshot" of the world
- it helps neurodivergent people on versioning their world

Version numbers are defined as PROJECT.MAJOR.MINOR, where you increment the:
-
PROJECTsegment when you want the version to be considered a new, major overhauled project (e.g. Sdl 2.28 to Sdl 3.0). -
MAJORsegment when you make continuity changes, like minor retcon, not major enough to change the foundation. -
MINORsegment when you make content changes (e.g. formalize canonized entries, etc.) with no to very micro retcon.
Additional labels for pre-release and build metadata are available as extensions to the PROJECT . MAJOR . MINOR format.
[WIP]
A WorldVer release represents a "snapshot" of the canonical world. Changes to repository structure, documentation, tooling, or other non-canonical material do not require a WorldVer release unless they alter the canonical state or are included as part of a release.
If a worldbuilding project wishes to use WorldVer, it must follow these rules:
-
The rules use this definition to define the changes. Although i prefer it to be open for interpretation by the user of this versioning.
-
Foundation is The fundamental premise, identity, scope, or structure that defines what a world is.
-
Continuity is The established relationships between facts, events, entities, and other elements of the world. A continuity change is retcon.
-
Content is Information that adds, expands, formalizes, corrects, or reorganizes the world without changing established canon.
-
-
Version numbers must take the form
PROJECT.MAJOR.MINOR[-PRE][+BUILD]where PROJECT, MAJOR, and MINOR are non-negative integers with no leading zeroes, and PRE and BUILD are optional identifiers composed only of ASCII alphanumerics, hyphens, and dots. -
Once a release of the project is publicly available, its contents must never be modified. Any necessary modifications must be issued as a new release.
-
If a release defines a public data format, schema, identifier system, ontology, or other machine-readable interface intended for external use, that interface SHOULD be documented sufficiently for another person or tool to interpret it.
-
Project version zero (
0.*.*) must be used for initial development, where the project is marked as not stable and not foundationally complete. -
Each release's version number must be based off its predecessor's version number and must be changed according to the next three rules.
-
the PROJECT identifier must be incremented and the MAJOR and MINOR identifiers must be set to 0, If :
- the release is to be considered as a separate project/version lineage from older releases; or
- the world undergoes a foundational change that makes the new release heavily ruins the previous canon; or
- (and ONLY if the PROJECT Identifier is 0) the project is now marked as stable
-
Otherwise, the MAJOR identifier must be incremented and the MINOR identifier must be set to 0, if:
- the release introduces continuity change to established canon that does not ruin a foundational change, (e.g. retcon considered minor enough not to change the PROJECT)
-
Otherwise, the MINOR identifier must be incremented. Which should be, if:
- content is added, expanded, formalized, corrected, or reorganized without changing established canon
-
A pre-release version may be denoted by appending immediately following the MINOR identifier a hyphen and any ASCII string composed only of alphanumerics, dots, and hyphens. Pre-release identifiers, if included, must not be empty, and pre-release version numbers must only be issued for releases which are unstable previews for future releases.
Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
-
Build metadata may be denoted by appending immediately following the pre-release identifier (or otherwise the MINOR identifier) a plus sign and any ASCII string composed only of alphanumerics, dots, and hyphens. Build metadata identifiers, if included, must not be empty, and version numbers containing build metadata must only be issued for copies of the worldbuilding project included within a release, and not for a release itself.
Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
-
Precedence refers to how versions are compared when ordered, which must be computed by, in order:
-
comparing the PROJECT identifiers if they differ,
-
comparing the MAJOR identifiers if they differ,
-
comparing the MINOR identifiers if they differ,
-
If one has no PRE, it has higher precedence than one with PRE. compare the dot-separated PRE identifiers from left to right:
- numeric identifiers are compared numerically;
- alphabet identifiers are compared alphabetically;
- numeric identifiers have lower precedence than alphabet identifiers;
- if all compared identifiers are equal, the shorter sequence has lower precedence.
The presence (or lack thereof) of build metadata identifiers does not affect precedence, and pre-release version numbers have lower precedence than non-pre-release version numbers.
Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1 < 2.1.2-rc.01 < 2.1.2-rc.02 < 2.1.2.
-
[WIP]
If you add/release entries at periodic time (e.g. dungeon master), use CalVer or ChronVer, or any date based versioning
If you are tired of definitions, go try EffVer or Pride Versioning
You want to submit or contribute to the project? follow these steps
- Read our statements and agreements in Contributing
- Start authoring your articles!
- Tidy up your typings
And be sure to check out other document as well!
WIP
WIP