9 Versioning

Rumperuu edited this page 2021-04-29 18:34:28 +01:00

Unescape Escape

Table of Contents

• Versioning Style

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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.

Table of Contents

1. Home
2. Project Layout
   1. Repo. Root
   2. Plugin Source Directory
      1. Plugin Classes Directory
         1. Plugin Dashboard Directory
         2. Plugin Widgets Directory
   3. Plugin Stylesheets Directory
   4. Plugin Images Directory
   5. Plugin Scripts Directory
   6. Plugin Translations Directory
   7. Plugin Templates Directory
3. Git Tips
4. Versioning
5. SVN Release Guide

Appendices

1. Custom Template Stack
2. Customised Documentation Schema