Given a release, its version is: 1. YY.MM.DD, the UTC date of the release, with every part two digits (26.10.01), or 2. YY.MM.DD-N when it is not the first release on that date, where N counts the extra releases that day, starting at 1 (26.10.01-1, 26.10.01-2, …). From the year 2100, when two digits can no longer tell the century, the year is written in full: 2100.01.01. Date Versioning works for every year from 2000 on, with no end date. Later versions always have greater precedence: dates compare in order, and on the same date 26.10.01 < 26.10.01-1 < 26.10.01-2. Given a release, its version is: 1. `YY.MM.DD`, the UTC date of the release, with every part two digits (`26.10.01`), or 2. `YY.MM.DD-N` when it is not the first release on that date, where `N` counts the extra releases that day, starting at 1 (`26.10.01-1`, `26.10.01-2`, …). From the year 2100, when two digits can no longer tell the century, the year is written in full: `2100.01.01`. Date Versioning works for every year from 2000 on, with no end date. Later versions always have greater precedence: dates compare in order, and on the same date `26.10.01` < `26.10.01-1` < `26.10.01-2`.

A version number usually answers "what changed?". A Date Version answers "when was this released?", and does so in a form that people, programs and AI tools can read, write, validate and sort without guesswork. Date Versioning suits projects that release continuously, ship on their own schedule, or find that choosing between "major", "minor" and "patch" adds little. Date Versioning looks like Semantic Versioning (https://semver.org) (three numbers separated by dots, an optional suffix after a hyphen and optional build metadata after a plus sign), and it borrows SemVer's structure and wording. It is not SemVer: the parts mean something different, they are zero-padded, and the -N suffix ranks after the version it follows, not before. Compatibility with Semantic Versioning explains how the two fit together. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (https://www.rfc-editor.org/rfc/rfc2119). A version number usually answers "what changed?". A Date Version answers "when was this released?", and does so in a form that people, programs and AI tools can read, write, validate and sort without guesswork. Date Versioning suits projects that release continuously, ship on their own schedule, or find that choosing between "major", "minor" and "patch" adds little. Date Versioning looks like [Semantic Versioning](https://semver.org) (three numbers separated by dots, an optional suffix after a hyphen and optional build metadata after a plus sign), and it borrows SemVer's structure and wording. It is **not** SemVer: the parts mean something different, they are zero-padded, and the `-N` suffix ranks *after* the version it follows, not before. [Compatibility with Semantic Versioning](#compatibility-with-semantic-versioning) explains how the two fit together. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119).

1. Software using Date Versioning MUST declare that it does, for example in its README or documentation, and SHOULD link to https://datevers.ing. 2. A normal version number MUST take the form YY.MM.DD, or YYYY.MM.DD from the year 2100 (rule 12), where: - YY is the year minus 2000, from 00 to 99 (26 is 2026), for the years 2000 to 2099, - YYYY is the full year, for 2100 and later (2100), - MM is the month, from 01 to 12, - DD is the day of the month, from 01 to 31. YY, MM and DD MUST each be exactly two decimal digits, zero-padded (26.10.01, never 26.10.1). The date MUST be a real date in the Gregorian calendar (26.02.29 is not valid, because 2026 is not a leap year). 3. The date in a version MUST be the date, in Coordinated Universal Time (UTC), on which that version is released. A version MUST NOT carry a date in the future, and SHOULD NOT carry a date earlier than the day it is released. 4. Once a version has been released, its contents MUST NOT be modified. Any change MUST be released as a new version. 5. The first version released on a given UTC date MUST be YY.MM.DD, with no suffix. 6. Each further version released on the same UTC date MUST append a hyphen and a release number N: YY.MM.DD-N. N MUST be a decimal integer starting at 1 for the second release of the day and increasing by exactly 1 for each further release that day (-1, -2, -3, …). N MUST NOT be 0, MUST NOT have leading zeros and MUST NOT skip values. 7. Each new version MUST have greater precedence than every version released before it. A project MUST NOT release a version dated earlier than its latest version. 8. Build metadata MAY be added by appending a plus sign and a series of dot-separated identifiers immediately after the version: 26.10.01+build.7, 26.10.01-2+sha.5114f85. Identifiers MUST consist only of ASCII letters, digits and hyphens [0-9A-Za-z-] and MUST NOT be empty. Build metadata MUST be ignored when determining precedence, so two versions that differ only in build metadata have the same precedence. 9. Precedence is how versions are ordered. It MUST be calculated by comparing, in order: 1. the year numerically, where YY stands for the year 20YY (so 99 is 2099, and ranks below 2100), 2. MM numerically, 3. DD numerically, 4. the release number numerically, where a version with no -N has release number 0. The first difference decides. Example: 25.12.31 < 26.01.01 < 26.01.01-1 < 26.01.01-2 < 26.01.02 < 26.10.01. Up to 2099 every part is two digits, so comparing the YY.MM.DD parts of two versions as plain text gives the same result as comparing them numerically. That stops being true once a project reaches 2100 (as text, 99.12.31 sorts after 2100.01.01), so programs MUST compare the year as a number. The release number MUST also be compared numerically (-10 is greater than -9). 10. Date Versioning does not signal compatibility: a version says when a release happened, not what it changed. Breaking changes, deprecations and other notable changes MUST be described in the project's changelog or release notes for the version that introduces them. 11. A version MUST NOT include a prefix. In tags and other places where a prefix is customary, a v MAY be written in front of it (v26.10.01); v26.10.01 is a tag name, and its version is 26.10.01. 12. Date Versioning has no end date. The years 2000 to 2099 MUST be written as YY. From 2100, when YY could no longer tell the century, the year MUST be written in full (YYYY): the whole year, with as many digits as it needs and no leading zeros (2100.01.01, 2345.06.07-1, and in the year 10000, 10000.01.01). The full year MUST NOT be used for the years 2000 to 2099 (2026.10.01 is not valid; it is 26.10.01), so every release date has exactly one Date Version. 99.12.31 is followed by 2100.01.01, which has greater precedence (rule 9). 13. A project that adopts Date Versioning after using another versioning scheme MUST say so in the changelog entry for its first Date Version. Versions released under the earlier scheme are not Date Versions and MUST NOT be compared with Date Versions using these rules: every Date Version ranks above every version the project released before the switch. Where the project publishes SemVer forms (see Compatibility with Semantic Versioning), the SemVer form of its first Date Version MUST rank above every version it has already published. If it would not, as when the project is already at a major version of YY or more (for example 30.2.1 before a first Date Version of 26.10.01), the project MUST choose a major offset: the smallest multiple of 100 that makes the SemVer form of its first Date Version rank above every earlier version. The offset is added to MAJOR in every SemVer form the project publishes from then on (26.10.01 becomes 126.10.100 with an offset of 100). It MUST be stated alongside the project's declaration that it uses Date Versioning (rule 1) and MUST NOT change. A project with no major offset has an offset of 0. 1. Software using Date Versioning MUST declare that it does, for example in its README or documentation, and SHOULD link to https://datevers.ing. 2. A normal version number MUST take the form `YY.MM.DD`, or `YYYY.MM.DD` from the year 2100 (rule 12), where: - `YY` is the year minus 2000, from `00` to `99` (`26` is 2026), for the years 2000 to 2099, - `YYYY` is the full year, for 2100 and later (`2100`), - `MM` is the month, from `01` to `12`, - `DD` is the day of the month, from `01` to `31`. `YY`, `MM` and `DD` MUST each be exactly two decimal digits, zero-padded (`26.10.01`, never `26.10.1`). The date MUST be a real date in the Gregorian calendar (`26.02.29` is not valid, because 2026 is not a leap year). 3. The date in a version MUST be the date, in **Coordinated Universal Time (UTC)**, on which that version is released. A version MUST NOT carry a date in the future, and SHOULD NOT carry a date earlier than the day it is released. 4. Once a version has been released, its contents MUST NOT be modified. Any change MUST be released as a new version. 5. The first version released on a given UTC date MUST be `YY.MM.DD`, with no suffix. 6. Each further version released on the same UTC date MUST append a hyphen and a **release number** `N`: `YY.MM.DD-N`. `N` MUST be a decimal integer starting at `1` for the second release of the day and increasing by exactly 1 for each further release that day (`-1`, `-2`, `-3`, …). `N` MUST NOT be `0`, MUST NOT have leading zeros and MUST NOT skip values. 7. Each new version MUST have greater precedence than every version released before it. A project MUST NOT release a version dated earlier than its latest version. 8. Build metadata MAY be added by appending a plus sign and a series of dot-separated identifiers immediately after the version: `26.10.01+build.7`, `26.10.01-2+sha.5114f85`. Identifiers MUST consist only of ASCII letters, digits and hyphens `[0-9A-Za-z-]` and MUST NOT be empty. Build metadata MUST be ignored when determining precedence, so two versions that differ only in build metadata have the same precedence. 9. Precedence is how versions are ordered. It MUST be calculated by comparing, in order: 1. the year numerically, where `YY` stands for the year `20YY` (so `99` is 2099, and ranks below `2100`), 2. `MM` numerically, 3. `DD` numerically, 4. the release number numerically, where a version with no `-N` has release number `0`. The first difference decides. Example: `25.12.31` < `26.01.01` < `26.01.01-1` < `26.01.01-2` < `26.01.02` < `26.10.01`. Up to 2099 every part is two digits, so comparing the `YY.MM.DD` parts of two versions as plain text gives the same result as comparing them numerically. That stops being true once a project reaches 2100 (as text, `99.12.31` sorts after `2100.01.01`), so programs MUST compare the year as a number. The release number MUST also be compared numerically (`-10` is greater than `-9`). 10. Date Versioning does not signal compatibility: a version says when a release happened, not what it changed. Breaking changes, deprecations and other notable changes MUST be described in the project's changelog or release notes for the version that introduces them. 11. A version MUST NOT include a prefix. In tags and other places where a prefix is customary, a `v` MAY be written in front of it (`v26.10.01`); `v26.10.01` is a tag name, and its version is `26.10.01`. 12. Date Versioning has no end date. The years 2000 to 2099 MUST be written as `YY`. From 2100, when `YY` could no longer tell the century, the year MUST be written **in full** (`YYYY`): the whole year, with as many digits as it needs and no leading zeros (`2100.01.01`, `2345.06.07-1`, and in the year 10000, `10000.01.01`). The full year MUST NOT be used for the years 2000 to 2099 (`2026.10.01` is not valid; it is `26.10.01`), so every release date has exactly one Date Version. `99.12.31` is followed by `2100.01.01`, which has greater precedence (rule 9). 13. A project that adopts Date Versioning after using another versioning scheme MUST say so in the changelog entry for its first Date Version. Versions released under the earlier scheme are not Date Versions and MUST NOT be compared with Date Versions using these rules: every Date Version ranks above every version the project released before the switch. Where the project publishes SemVer forms (see [Compatibility with Semantic Versioning](#compatibility-with-semantic-versioning)), the SemVer form of its first Date Version MUST rank above every version it has already published. If it would not, as when the project is already at a major version of `YY` or more (for example `30.2.1` before a first Date Version of `26.10.01`), the project MUST choose a **major offset**: the smallest multiple of 100 that makes the SemVer form of its first Date Version rank above every earlier version. The offset is added to MAJOR in every SemVer form the project publishes from then on (`26.10.01` becomes `126.10.100` with an offset of 100). It MUST be stated alongside the project's declaration that it uses Date Versioning (rule 1) and MUST NOT change. A project with no major offset has an offset of 0.

A Date Version has the same shape as a Semantic Version, but two rules differ: - Zero padding. SemVer forbids leading zeros, so strict SemVer parsers reject 26.10.01. - The -N suffix. In SemVer, 26.10.1-1 is a pre-release that ranks before 26.10.1. In DateVer, 26.10.01-1 ranks after 26.10.01. So a Date Version MUST NOT be compared using SemVer rules, and where a registry or tool only accepts SemVer (npm, Cargo, Composer and others), the version MUST be written in its SemVer form: DateVer part | SemVer form | Rule -------------+-------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- YY or YYYY | MAJOR | The year minus 2000 (YY without leading zeros up to 2099), plus the project's major offset if it has one (rule 13): 26 → 26, 05 → 5, 2100 → 100, 26 with an offset of 100 → 126 MM | MINOR | MM without leading zeros (10 → 10, 01 → 1) DD and -N | PATCH | DD × 100 + N, where N is 0 when there is no suffix Date Version | SemVer form ---------------------------+------------ 26.10.01 | 26.10.100 26.10.01-1 | 26.10.101 26.10.01-2 | 26.10.102 26.10.31 | 26.10.3100 05.03.09-4 | 5.3.904 26.10.01, major offset 100 | 126.10.100 2100.01.01 | 100.1.100 2345.06.07-1 | 345.6.701 The SemVer form sorts correctly under SemVer rules, including across 2100 (99.12.31 is 99.12.3100, then 2100.01.01 is 100.1.100), and it converts back exactly: the year is 2000 + MAJOR − offset (written as YY up to 2099 and in full from 2100), DD is PATCH ÷ 100 rounded down and N is PATCH mod 100. Build metadata is carried over unchanged. A project that publishes SemVer forms MUST NOT release more than 99 versions after the first on one date (-99 is the highest release number with a SemVer form). A project MUST use one form per place it publishes, and SHOULD use the canonical YY.MM.DD form everywhere SemVer is not required (its changelog, tags, release titles and user interface). A Date Version has the same shape as a Semantic Version, but two rules differ: - **Zero padding.** SemVer forbids leading zeros, so strict SemVer parsers reject `26.10.01`. - **The `-N` suffix.** In SemVer, `26.10.1-1` is a pre-release that ranks *before* `26.10.1`. In DateVer, `26.10.01-1` ranks *after* `26.10.01`. So a Date Version MUST NOT be compared using SemVer rules, and where a registry or tool only accepts SemVer (npm, Cargo, Composer and others), the version MUST be written in its **SemVer form**: | DateVer part | SemVer form | Rule | | --- | --- | --- | | `YY` or `YYYY` | MAJOR | The year minus 2000 (`YY` without leading zeros up to 2099), plus the project's major offset if it has one (rule 13): `26` → `26`, `05` → `5`, `2100` → `100`, `26` with an offset of 100 → `126` | | `MM` | MINOR | `MM` without leading zeros (`10` → `10`, `01` → `1`) | | `DD` and `-N` | PATCH | `DD × 100 + N`, where `N` is `0` when there is no suffix | | Date Version | SemVer form | | --- | --- | | `26.10.01` | `26.10.100` | | `26.10.01-1` | `26.10.101` | | `26.10.01-2` | `26.10.102` | | `26.10.31` | `26.10.3100` | | `05.03.09-4` | `5.3.904` | | `26.10.01`, major offset 100 | `126.10.100` | | `2100.01.01` | `100.1.100` | | `2345.06.07-1` | `345.6.701` | The SemVer form sorts correctly under SemVer rules, including across 2100 (`99.12.31` is `99.12.3100`, then `2100.01.01` is `100.1.100`), and it converts back exactly: the year is `2000 + MAJOR − offset` (written as `YY` up to 2099 and in full from 2100), `DD` is `PATCH ÷ 100` rounded down and `N` is `PATCH mod 100`. Build metadata is carried over unchanged. A project that publishes SemVer forms MUST NOT release more than 99 versions after the first on one date (`-99` is the highest release number with a SemVer form). A project MUST use one form per place it publishes, and SHOULD use the canonical `YY.MM.DD` form everywhere SemVer is not required (its changelog, tags, release titles and user interface).

This regular expression (ECMAScript and PCRE compatible) checks the format, including the full year from 2100 (rule 12). A valid match must still be checked to be a real date in the Gregorian calendar (rule 2): February has 29 days in years divisible by 4, except century years not divisible by 400 (2100 is not a leap year; 2400 is). ^(?<year>[0-9]{2}|2[1-9][0-9]{2}|[3-9][0-9]{3}|[1-9][0-9]{4,})\.(?<month>0[1-9]|1[0-2])\.(?<day>0[1-9]|[12][0-9]|3[01])(?:-(?<release>[1-9][0-9]*))?(?:\+(?<build>[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?$ Without named groups: ^([0-9]{2}|2[1-9][0-9]{2}|[3-9][0-9]{3}|[1-9][0-9]{4,})\.(0[1-9]|1[0-2])\.(0[1-9]|[12][0-9]|3[01])(?:-([1-9][0-9]*))?(?:\+([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?$ This regular expression (ECMAScript and PCRE compatible) checks the format, including the full year from 2100 (rule 12). A valid match must still be checked to be a real date in the Gregorian calendar (rule 2): February has 29 days in years divisible by 4, except century years not divisible by 400 (2100 is not a leap year; 2400 is). ```regex ^(?<year>[0-9]{2}|2[1-9][0-9]{2}|[3-9][0-9]{3}|[1-9][0-9]{4,})\.(?<month>0[1-9]|1[0-2])\.(?<day>0[1-9]|[12][0-9]|3[01])(?:-(?<release>[1-9][0-9]*))?(?:\+(?<build>[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?$ ``` Without named groups: ```regex ^([0-9]{2}|2[1-9][0-9]{2}|[3-9][0-9]{3}|[1-9][0-9]{4,})\.(0[1-9]|1[0-2])\.(0[1-9]|[12][0-9]|3[01])(?:-([1-9][0-9]*))?(?:\+([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?$ ```

To pick the version for a new release: 1. Take today's date in UTC as YY.MM.DD (as YYYY.MM.DD from 2100). 2. If the project has no version on that date yet, the version is YY.MM.DD. 3. Otherwise, find the highest release number already used on that date (0 if only YY.MM.DD exists) and add 1: YY.MM.DD-N. For example, with latest version 26.09.30, a release on 1 October 2026 (UTC) is 26.10.01, the next one that day is 26.10.01-1, and the first release on 2 October is 26.10.02. To pick the version for a new release: 1. Take today's date in UTC as `YY.MM.DD` (as `YYYY.MM.DD` from 2100). 2. If the project has no version on that date yet, the version is `YY.MM.DD`. 3. Otherwise, find the highest release number already used on that date (`0` if only `YY.MM.DD` exists) and add 1: `YY.MM.DD-N`. For example, with latest version `26.09.30`, a release on 1 October 2026 (UTC) is `26.10.01`, the next one that day is `26.10.01-1`, and the first release on 2 October is `26.10.02`.

When a project ships often, or its releases don't divide neatly into major, minor and patch changes, the most useful thing a version can tell you is when it was released. A Date Version tells you at a glance how old a release is, sorts correctly, and leaves nothing to decide at release time. When a project ships often, or its releases don't divide neatly into major, minor and patch changes, the most useful thing a version can tell you is when it was released. A Date Version tells you at a glance how old a release is, sorts correctly, and leaves nothing to decide at release time.

Use SemVer when other software depends on yours and needs the version to promise compatibility, as libraries usually do. Date Versioning deliberately makes no such promise (rule 10). Use SemVer when other software depends on yours and needs the version to promise compatibility, as libraries usually do. Date Versioning deliberately makes no such promise (rule 10).

In the changelog or release notes for that version. A Date Version only says when; what changed belongs in the changelog. Keeping a changelog is strongly RECOMMENDED for every project that uses Date Versioning. In the changelog or release notes for that version. A Date Version only says when; what changed belongs in the changelog. Keeping a changelog is strongly RECOMMENDED for every project that uses Date Versioning.

No. In Date Versioning, -N is the release number: 26.10.01-1 is the second release on 1 October 2026, and it ranks above 26.10.01. This is the main difference from SemVer, which is why Date Versions must not be compared using SemVer rules. No. In Date Versioning, `-N` is the release number: `26.10.01-1` is the second release on 1 October 2026, and it ranks above `26.10.01`. This is the main difference from SemVer, which is why Date Versions must not be compared using SemVer rules.

Date Versioning has no pre-release syntax, because every Date Version is a release. Publish previews on a separate channel (a beta branch, a "next" tag on your registry, a test track), and label preview builds with build metadata if you need to (26.10.01+beta.1), remembering that build metadata does not affect precedence. Date Versioning has no pre-release syntax, because every Date Version is a release. Publish previews on a separate channel (a beta branch, a "next" tag on your registry, a test track), and label preview builds with build metadata if you need to (`26.10.01+beta.1`), remembering that build metadata does not affect precedence.

So that the same moment has the same date for everyone. Without it, a team spread across time zones could disagree about a release's date, or produce a version that sorts before the one released minutes earlier. So that the same moment has the same date for everyone. Without it, a team spread across time zones could disagree about a release's date, or produce a version that sorts before the one released minutes earlier.

Yes, if UTC was still on the previous day. The date is always the UTC date (rule 3). Yes, if UTC was still on the previous day. The date is always the UTC date (rule 3).

So that every Date Version reads unambiguously as a date, has the same length, and sorts correctly as plain text. Use the SemVer form where a tool insists on unpadded numbers. So that every Date Version reads unambiguously as a date, has the same length, and sorts correctly as plain text. Use the SemVer form where a tool insists on unpadded numbers.

Publish the SemVer form (26.10.01-2 → 26.10.102) there, and use the canonical form everywhere else. See Compatibility with Semantic Versioning. Publish the SemVer form (`26.10.01-2` → `26.10.102`) there, and use the canonical form everywhere else. See [Compatibility with Semantic Versioning](#compatibility-with-semantic-versioning).

Not as the version. A v is fine in tag names (v26.10.01), as it is with SemVer (rule 11). Not as the version. A `v` is fine in tag names (`v26.10.01`), as it is with SemVer (rule 11).

No. The second release of the day is -1, then -2, and so on, with no gaps (rule 6). That way the release number always tells you how many releases came before it that day. No. The second release of the day is `-1`, then `-2`, and so on, with no gaps (rule 6). That way the release number always tells you how many releases came before it that day.

Leave it: a released version must never change (rule 4). Release the fix as a new version with the correct date. If the wrong date was in the future, the next releases must still rank above it (rule 7), so add release numbers on that date until real time catches up. Leave it: a released version must never change (rule 4). Release the fix as a new version with the correct date. If the wrong date was in the future, the next releases must still rank above it (rule 7), so add release numbers on that date until real time catches up.

Release your next version with today's date, and say in that version's changelog entry that the project now uses Date Versioning (rule 13). Every Date Version ranks above every version from before the switch. If tools see your versions as SemVer, check the SemVer form of your first Date Version: 26.10.01 is 26.10.100, which ranks above any version with a major number below 26, so for almost every project nothing else is needed. If your project is already at a major version of 26 or more (say 30.2.1), give it a major offset of 100, as rule 13 describes: its SemVer forms then start at 126.10.100 and keep ranking above the old versions. The Date Versions themselves don't change. Release your next version with today's date, and say in that version's changelog entry that the project now uses Date Versioning (rule 13). Every Date Version ranks above every version from before the switch. If tools see your versions as SemVer, check the SemVer form of your first Date Version: `26.10.01` is `26.10.100`, which ranks above any version with a major number below 26, so for almost every project nothing else is needed. If your project is already at a major version of 26 or more (say `30.2.1`), give it a major offset of 100, as rule 13 describes: its SemVer forms then start at `126.10.100` and keep ranking above the old versions. The Date Versions themselves don't change.

Nothing breaks. From 1 January 2100 (UTC), Date Versions write the year in full: the first release that day is 2100.01.01, which ranks above 99.12.31 (rules 9 and 12). The full year keeps working for as long as there are years to count, so a project never has to change scheme. In the SemVer form the year carries on past 99 as well: 2100.01.01 is 100.1.100. Nothing breaks. From 1 January 2100 (UTC), Date Versions write the year in full: the first release that day is `2100.01.01`, which ranks above `99.12.31` (rules 9 and 12). The full year keeps working for as long as there are years to count, so a project never has to change scheme. In the SemVer form the year carries on past 99 as well: `2100.01.01` is `100.1.100`.

With Date Versioning. This is Date Versioning 26.10.01-2, the third version of the specification released on 1 October 2026. With Date Versioning. This is Date Versioning `26.10.01-2`, the third version of the specification released on 1 October 2026.

Date Versioning is a versioning standard created and maintained by Stux.Group (https://stux.group). Its source, history and issue tracker are at https://github.com/StuxGroup/DateVersioning. Date Versioning is a versioning standard created and maintained by [Stux.Group](https://stux.group). Its source, history and issue tracker are at https://github.com/StuxGroup/DateVersioning.

Copyright © 2026 Stux.Group. This specification is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0) (https://creativecommons.org/licenses/by/4.0/). You may share and adapt it, including commercially, as long as you give appropriate credit. Copyright © 2026 Stux.Group. This specification is licensed under [Creative Commons Attribution 4.0 International (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/). You may share and adapt it, including commercially, as long as you give appropriate credit.