Use Github's tagged versions to detect if new version is available

[e2jk]

Up until v0.0.42beta, the function checkUpdate got it's latest version from @sebsauvage's website:
http://sebsauvage.net/files/shaarli_version.txt

Now that tagged versions will be available in GitHub (after #3 is merged and v0.0.42beta is released), the availability of a new version should be checked from https://github.com/shaarli/Shaarli/releases directly, which avoids having to update the version number on Seb's website (which has to be a manual action by himself)

That Github page will list all available versions, so we need to detect the most recent (à la Debian watch files, if I may say so ;) ).

The updated function should be future-proof, in case the versioning scheme changes from "0.0.Xbeta" to something a bit more conventional (see #4)

[Marsup]

It would be better done through https://api.github.com/repos/shaarli/Shaarli/tags.
Beware you need to set a User-Agent for that query.

I recently did it on another project (not php) with a semver module, works very well. It seems https://github.com/vierbergenlars/php-semver is a php port from the module I used, you just have to iterate on the list to eliminate names that are not .valid() and sort with rcompare, then compare the 1st one with what you have.

[nodiscc]

Or we could use the tags atoms feed to check for new versions: https://github.com/shaarli/Shaarli/tags.atom.

Or - maybe even better because is not github-specific and totally future proof - check against shaarli_version in https://raw.githubusercontent.com/shaarli/Shaarli/master/index.php. (much more portable, but this would mean always keeping the master branch in a working, releasable state).

[Sbgodin]

I also vote for master to be the stable branch. We might use a dev branch, which would contain a usable software on the developpeur point of view. If a function in development make the code unstable, then it'll be on a feature branch until the merge to dev.

[Sbgodin]

About the update check, imho it should follow such guidelines:

• The user is fully aware of it existence.
• The user must enable it himself
• The user must be aware of the privacy concern (privacy vs. function)

The good thing would be to register to the update message service with a dedicated software. Erm... Do we have a something that tracks the updates on the code and something to stay in touch with such news? I heard about RSS ;-)

[nodiscc]

The user must enable it himself

Totally agree. Maybe a checkbox at setup and in the configure dialog:

• Automatically check for updates. This will periodically check the author's code repository for new versions. Your current version is $shaarli_version. You can also stay informed of latest updates by subscribing to the releases feed

[Sbgodin]

👍

[nodiscc]

Having a better release policy would help with these issues:

• Fixes L'extraction du fichier zip renvoie une erreur sebsauvage/Shaarli#47: fichier zip corrompu (just use the master zipball from github) download instructions updated
• Fixes please use git-tags sebsauvage/Shaarli#77: please use git-tags tracked in Question: Change versioning schema? #4
• Fixes Flux RSS pour les releases sebsauvage/Shaarli#79: Flux RSS pour les releases tracked in Question: Change versioning schema? #4
• Mise à jour 0.0.40 vers 0.0.41 sebsauvage/Shaarli#86: Mise à jour 0.0.40 vers 0.0.41 (DATA LOSS) upgrade instructions updated

[nodiscc]

Sorry this is not closed (it closed because of #31 message, wich is wrong)

[nodiscc]

I will now close this, please read #4 (comment) for an explanation. Using shaarli_version.txt for update checks is fine. We will still tags future versions.