This is a good idea, when you're running the script...there should be some form of hardcoded version in each release. Maybe this would require you making new branches on the release and then making 1 commit on that branch to update version, and release it off that. I've seen this done in Pterodactyl and it works well there.
With that, we can have an update that just quickly gets the latest release from the GitHub API and compares (assuming the version is not canary). This would allow people to know if they're on the latest release or not.
EDIT: Details for Pterodactyl. Recently, when a release is being made...they'll make a branch based off master after everything is merged and the branch will be called release/vX.Y.Z. The release will be based of and tagged at that moment for future storing. Or you can just seperate the branches into a master/develop standard and just use master for releases and worry about all that diff management then.
This is a good idea, when you're running the script...there should be some form of hardcoded version in each release. Maybe this would require you making new branches on the release and then making 1 commit on that branch to update version, and release it off that. I've seen this done in Pterodactyl and it works well there.
With that, we can have an update that just quickly gets the latest release from the GitHub API and compares (assuming the version is not
canary). This would allow people to know if they're on the latest release or not.EDIT: Details for Pterodactyl. Recently, when a release is being made...they'll make a branch based off master after everything is merged and the branch will be called
release/vX.Y.Z. The release will be based of and tagged at that moment for future storing. Or you can just seperate the branches into a master/develop standard and just use master for releases and worry about all that diff management then.