Versioning

Note: this document is meant for developers. If you have no interest in pyfa development, then this doesn't offer you much

With the new update notification feature, Pyfa will check GitHub at every startup (unless otherwise told not to), and compare the current version to the latest release tag. We must be very strict with how we handle versioning and releases. These are my thoughts and partly documentation to how the notifications work.

Stable release

version = "1.1.20"
tag = "Stable"
expansionName = "Rubicon"
expansionVersion = "1.1"

This shows the version and the tag Stable. This is already done, and nothing new needs to happen. However, after a stable release is made, increment version by one and tag = "git" to signify development of the next version. This is very important, otherwise things may break in the updater logic.

Singularity pre-release

version = "1.1.21"
tag = "git"
expansionName = "Singularity"
expansionVersion = "703519"

This signifies that it is still a development release with tag="git", but that the release is for Singularity and it reports the version for the SiSi server it corresponds to. version should still be a higher increment than the current stable release.

It's possible to append -# to the end of the Singularity version (and release tag) to trigger a new notification, ie: expansionVersion = "703519-2". This may be helpful in case there are multiple releases for the same SiSi version (or for feature pre-releases not necessarily chained to a SiSi version)

Algorithm

1. Check GitHub for release info.
2. If latest release is a pre-release and we've chosen to suppress them, then increment release count by 1 and continue loop
3. Do other stuff

Use cases:

These are cases that need to be checked for proper notifications

• Old release (v1.1.16 - Stable) to new release (v1.1.20 - Stable).
• Old release (v1.1.16 - Stable) to new Singularity (singularity-703519).
• Old Singularity (singularity-597398) to new Singularity (singularity-703519)
• Old Singularity (singularity-597398) to new release (v1.1.20 - Stable)
  • This is why it in important to increment version by 1 immediately after release and tag it as git. Singularity still has this git tag and dev version, and so it will compare the release and the internal version - if the internal version is the same or higher, then that means there is a stable release that should supersede current Singularity release.
• Dev release (v1.1.20 - git) to stable release (v1.1.20 - Stable)