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, we must be strict with how we handle versioning and releases. These are my thoughts and partly documentation to how the notifications work.

Pyfa will check GitHub at every startup (unless otherwise told not to), and compare the current version to the latest release tag. At the moment, it only compares stable releases, and still notifies you of pre-releases. However, I would also like to compare pre-releases as well, and a slight change in versioning may be required for that.

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, I propose to increment version by one and tag = "git" to signify development of the next version. This has happened sometimes, but sometimes it's forgotten.

Singularity 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 1 increment above current stable release.

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)
  • Do we want to compare pure dev versions with stable releases?

Also: Will there ever be a pre-release that is not necessarily based on Singularity? Perhaps a pre-release for a new feature or bug fix?