Skip to content

guidelines git_specification versioning

GitHub Action edited this page Aug 28, 2026 · 2 revisions

WorldVer, Versioning for Worldbuilding

Note

WorldVer currently adapted from RomVer. Feedback is welcome.

There is also a Conventional Commits specifiication made for Worldbuilding in the repo.

Introduction

This is an adaptation of the RomVer format. Made specifically for worldbuilding

The Romantic Versioning specification was originally authored by Daniel V in 2015.

Why was this made and Why should this be used?

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

Spec Summary

scrapped from RomVer github

Version numbers are defined as PROJECT.MAJOR.MINOR, where you increment the:

  1. PROJECT segment when you want the version to be considered a new, major overhauled project (e.g. Sdl 2.28 to Sdl 3.0).

  2. MAJOR segment when you make continuity changes, like minor retcon, not major enough to change the foundation.

  3. MINOR segment 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.

Example

[WIP]

Full WorldVer Specification

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:

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

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

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

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

  5. Project version zero (0.*.*) must be used for initial development, where the project is marked as not stable and not foundationally complete.

  6. Each release's version number must be based off its predecessor's version number and must be changed according to the next three rules.

  7. the PROJECT identifier must be incremented and the MAJOR and MINOR identifiers must be set to 0, If :

    1. the release is to be considered as a separate project/version lineage from older releases; or
    2. the world undergoes a foundational change that makes the new release heavily ruins the previous canon; or
    3. (and ONLY if the PROJECT Identifier is 0) the project is now marked as stable
  8. Otherwise, the MAJOR identifier must be incremented and the MINOR identifier must be set to 0, if:

    1. 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)
  9. Otherwise, the MINOR identifier must be incremented. Which should be, if:

    1. content is added, expanded, formalized, corrected, or reorganized without changing established canon
  10. 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.

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

  12. Precedence refers to how versions are compared when ordered, which must be computed by, in order:

    1. comparing the PROJECT identifiers if they differ,

    2. comparing the MAJOR identifiers if they differ,

    3. comparing the MINOR identifiers if they differ,

    4. If one has no PRE, it has higher precedence than one with PRE. compare the dot-separated PRE identifiers from left to right:

      1. numeric identifiers are compared numerically;
      2. alphabet identifiers are compared alphabetically;
      3. numeric identifiers have lower precedence than alphabet identifiers;
      4. 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.

Versioning Workflow Diagram

[WIP]

Other Versioning suitable for Worldbuilding

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

License

Creative Commons Attribution 4.0 International

Navigate from here!

You want to submit or contribute to the project? follow these steps

  1. Read our statements and agreements in Contributing
  2. Start authoring your articles!
  3. Tidy up your typings

And be sure to check out other document as well!

Our Legal Documents

WIP

About the World

Guidelines

Articles about Worldbuilding

WIP

Clone this wiki locally