-
Notifications
You must be signed in to change notification settings - Fork 5
Versioning
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.
- 2.5.1 and identical to the release found in
- the ‘Stable Tag’ field in
trunk/readme.txt
will point totags/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.