Skip to content

Versioning

Rumperuu edited this page Apr 29, 2021 · 9 revisions

Versioning Style

footnotes uses Semantic Versioning 2.0.0.

A version identifier consists of three integers, separated by dots:

  • The first integer represents a Major Version.
  • The second integer represents a Minor Version.
  • The third integer represents a Bugfix Version.

On top of this, footnotes version identifiers can be appended with one of two flags:

  • d, indicating a development release
    • e.g., ‘2.5.2d’
    • This should only be found on the Git repo.
    • The version number should always be one higher than the version number listed in the ‘Stable Tag’ field in readme.txt
    • There are no individually-numbered development releases
  • p, indicating a pre-release
    • e.g., ‘2.5.2p’
    • This should only be found on the SVN repo. in trunk/
    • The version number should always be one higher than the version number listed in the ‘Stable Tag’ field in readme.txt
    • There are no individually-numbered pre-releases

So, to summarise:

  • if 2.5.1 is the latest stable release available on the SVN repo. (from tags/2.5.1/);
  • the codebase in the main branch on the Git repo. is 3.0.0d, 2.6.0d or 2.5.2d;
  • the codebase in trunk/ on the SVN repo. is either:
    • 2.5.1 and identical to the release found in tags/2.5.1/; OR
    • 3.0.0p, 2.6.0p or 2.5.2p.
  • the ‘Stable Tag’ field in trunk/readme.txt will point to tags/2.5.1/.

When a pre-release version is confirmed to be stable, remove the p flag, copy trunk/ to tags/<new-version>/ and update the ‘Stable Tag’ field in trunk/readme.txt to point to <new-version>.

IN SHORT: There is only ever one d and one p codebase. The d codebase continuously changes until it is ready to be frozen as a p codebase and pre-released to trunk/. The p codebase then continuously changes (but hopefully not much) until it ready to be frozen as a full release (i.e., the p codebase should receive no additional features or bugfixes, just whatever needs to be done to make the already-implemented ones work correctly if there are issues).

IN EVEN SHORTER: d codebases should live as long as they need to. p codebases should be short-lived.