A 'gap' in version checking?

[mgrabow1]

My code:

$myUpdateChecker = Puc_v4_Factory::buildUpdateChecker( 'https://github.com/mgrabow1/private-repo/', __FILE__, 'my-slug' );
$myUpdateChecker->getVcsApi()->enableReleaseAssets();
$myUpdateChecker->setAuthentication('my-secret-token');

My plugin is built tagged and released by a Github workflow. There is only one zip artifact per release (apart from the source archives). Everything is in the main branch.

Steps:

1. I install version X (downloaded from release page).
2. I modify the plugin and the workflow bumps my version to X+1, creates a tag and a release.
3. Update checker claims that the version installed (X) is up to date.
4. I have added the code below to check what the Update checker actually receives from Github: error_log(print_r($myUpdateChecker->getVcsApi()->getLatestRelease(), true)); All data in that object say that the latest release is X+1 (tag_name, version, release, etc.) - so the updater gets correct information about X+1, but somehow still considers the plugin up to date.
5. I modify the plugin once again, creating version X+2 (and releasing it).
6. Now interesting thing happens - Update checker informs me about a new version and tells me the new version is X+1.
7. I perform the update.
8. The plugin updates to version X+2 (which is actually the newest version) :)

The cycle repeats - after creating X+3 nothing happens ("up to date"), but after building X+4 the updater informs me about X+3 version and then updates to the newest X+4 :)

It seems that somehow I get a gap (of one version) in version checking (although Github seems to be reporting the correct current version). Maybe some kind of a cache?

[mgrabow1]

So I performed one more test - I created a release 'by hand' (without the workflow) and it worked fine... Version X+1 was noticed by the Update checker. It seems there is something with releases I publish with my workflow that the cheker doesn't like :)

Can you give me some hints where to look for the function that decides if the available release is newer (in update chekcer of course)? I will eventually find it by myself, but maybe you could save me some time of analyzing a larger piece of your code :)

[YahnisElsts]

There is caching, but it should not create a "gap" effect like this. Usually, it would just mean that the update checker won't immediately detect the update unless you manually tell it to check for updates, such as by clicking the "Check for updates" link that's on the "Plugins -> Installed Plugins" page, below the plugin description.

The function that retrieves the latest release from GitHub is here: https://github.com/YahnisElsts/plugin-update-checker/blob/8a82397a6e04b8d344bfeac78d4c99e83e63e8b0/Puc/v4p13/Vcs/GitHubApi.php#L62-L106

Essentially, it just uses the GitHub API to get the latest release. It uses the associated tag name as the version number (it automatically removes the "v" prefix from tags like "v1.2"). That information is saved for later. When it's time to display available updates, the update checker calls PHP's built-in version_compare() function to determine if the latest release is newer than the installed version.

[mgrabow1]

My main problem with debugging this issue was that I didn't know what exact information the checker takes to compare with the version of plugin installed. I thought that it was the tag (version) itself, but it seems that it checks the version header of the main plugin file from the tagged branch (just as in your readme in "Stable branch" section).

And then I found the mistake in my workflow definition - it was creating a tag one commit before the one with version bump. So it released X+1 with X+1 tag, but the version inside main plugin file was still X... Next commit (X+2 tag) changed that version it to X+1 and that's why only then it was visible to the checker as a new version :)

Now it works as expected.

Thanks and sorry for the fuss!

[YahnisElsts]

Oops, you're right, I forgot about that part. It starts with the tag itself, but it will also try to download the main plugin file and extract the version header from the file. If it finds the header, it will use that instead of the tag name.

In any case, it's good to hear you figured it out.