New version details extracted from git master vs last release

[herrvigg]

When a new version is available, git-updater seems to extract the version details from the latest commit of master. In the changelog tab it shows "Requires WordPress Version" and "Requires PHP Version".

However these data may have changed in master though git-updater is supposed to extract the last Release, not the last commit in master. So the information that is shown is incorrect, it doesn't correspond to the version deployed by git-updater which is confusing for system admins who deal with the requirements.

Also, in the Knowledge Base I can't find how the data are extracted. Is if from README or the plugin PHP file?

[afragen]

Git Updater gets all its information via API calls from the designated branch. If you are tagging releases then the download package comes from the latest release. Data is cached for 12 hours. If you are developing on your primary branch it's possible that some stale data is present.

Perhaps I'm not understanding?

[herrvigg]

Here is an example: https://github.com/qTranslate/qtranslate-xt. The last release is 3.14.0 with PHP requirement 5.5 (unspecified in the readme/qtranslate.php) and WP4.8. In master I'm currently preparing 3.15.0 with PHP7.1 and WP5.0.

On some of my prod site I was lagging behind, it proposed to install 3.14.0. In the details it shown the requirements as PHP7.1 and WP5.0 which is inconsistent with that release. It should have taken the info from 3.14.0, not the last one from master. Or there's something else I'm missing.

[afragen]

The WordPress and PHP requirements are taken from the main plugin file and are consistent with what you have presented.

[herrvigg]

Consistent with what? If it's taken from master it's not consistent with the last release. The info that is shown is not what is going to be installed.

[herrvigg]

Last release is not the same as last commit.

[herrvigg]

If I understand how it works, git-updater installs the releases from a git tag. So it should also be able to retrieve that information from the plugin file given by the same commit with that tag. But where is the tag extracted from?

[afragen]

There is no data extracted from a tagged release. The only data re: tag is the download package of the latest tag. All other data obtained from the primary branch.

The WP/PHP requirements are taken from the main plugin file.

https://developer.wordpress.org/plugins/plugin-basics/header-requirements/#header-fields

[afragen]

Since you have already committed the WP/PHP requirements to the primary branch, Git Updater has found them and uses them.

[herrvigg]

But git-updater installs the tagged version, not the last commit, doesn't it? Is the git tag deduced from the Version field from the plugin header?

[afragen]

The tag is returned from an API call.

[afragen]

https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#get-the-latest-release

[afragen]

https://git-updater.com/knowledge-base/versions-branches/

[herrvigg]

Thanks for this information. I'll dig a bit into it and see if there's something possible (it would be an improvement in that case).

[herrvigg]

My logic would be: 1- find the git tag corresponding to the last release (git API) 2- retrieve the corresponding git SHA if needed 3- extract the plugin information from the header given by that git commit (or tag directly)

That would make the following installation consistent with the information retrieved in (3).

[afragen]

The problem is you are actively working in your release branch. If you want to do that I would recommend you not update the version until you are ready to tag a release.

Otherwise I would suggest a git flow style of development.

[afragen]

What you're describing above is not how this plugin works.

[herrvigg]

The problem is you are actively working in your release branch.

What does that mean? The release branch is master, there's no other one. That's the most common way of working with git. Some call it also the stable branch. Developers can pull master at any time to get the most recent version. Development branches are only temporary. for new features fixes... until they are merged into master.

If you want to do that I would recommend you not update the version until you are ready to tag a release.

That's what I already do. When a new version is released, I update the plugin version and tag the release. That's what git-updater is expected to find, the last official release. This works fine, but the information that is extracted is not consistent with the release logic. IMO it should always use the same reference (git SHA or tag) for information retrieval and download (install).

[herrvigg]

For very big projects maybe several release branches are useful when maintaining multiple lines (e.g. fixes in version 1.x - while version 2.x is going forward). Maybe that's what you meant? But for smaller projects that's usually not the case, a single master is usually enough.

Anyway I don't think the branches change the logic of the release information. Given a branch (that is required by git-updater), the question remains the same - how to sync the information before install with the version that is effectively downloaded? the reference should always be the same.

[afragen]

Git Updater parses no data from any specific commit or tag. It only parses data from a branch.

I'm not really understanding what the issue seems to be. Is the data reported not present in the master branch in the main plugin file?

[herrvigg]

It's not enough to reason in terms of branches. What identifies and defines strictly a git version is the commit SHA and nothing else. A tag is simply a shortcut to mark a given commit. A branch is nothing more than a HEAD pointing to the last commit. As far as I know there's no special relation between tags and branches.

1) Last release (tag) Right now, this is my last official release: https://github.com/qtranslate/qtranslate-xt/blob/3.14.0/qtranslate.php#L6 This commit is frozen with tag 3.14.0. See there's no PHP or WP required version in the qtranslate file. This is what people will get from the last release. So far, so good.

2) Last commit (HEAD) Here is the last commit in master: https://github.com/qtranslate/qtranslate-xt/blob/728a9ae2ee56b039132deb87e7864ed4c6f23eef/qtranslate.php#L8 It has not been released yet. This defines a PHP and WP required version that will be used in next release.

Problem: (2) is what git-updater takes, but this is inconsistent with (1), the release that will be downloaded. It shows the information of a future release. It assumes the HEAD is pointing to the tagged commit but that assumption is wrong as soon as there's a new commit in that branch. It should retrieve the information from the commit related to tag 3.14.0, not the last one available in the branch of reference. Having one or multiple branches should not impact that behavior.

[herrvigg]

Ideally I would also like to increase the plugin version in master (HEAD) before release to show for example 3.15.0.dev.1 to the users (before release), but that created some problems of "infinite update-loop" with git-updater because of mismatch. This could be related to the same problem with extracted information.

[afragen]

This is the data parsed from the main plugin file. https://github.com/qtranslate/qtranslate-xt/blob/109da1d686fef52ef4557fa6bdeca19831813c4c/qtranslate.php#L6-L8

Your issue subject is exactly correct. No data is parsed from a specific commit, tag, or release. All data is parsed via API calls to the specified repository branch and the main plugin file in that branch.

I'm sorry if Git Updater doesn't behave like you want it to behave. If you have data in the main plugin file that is the primary data Git Updater uses. If you have tagged releases and Git Updater identifies a higher remote version from the data in the main plugin file then an update will register and Git Updater assumes that since you tag your releases that the latest tag is the one to use for the download package.

I invite you to read through the Knowledge Base to gain a better understanding of how Git Updater functions.

[herrvigg]

It's not so much for me but for all the users of git-updater. There must be a way to retrieve the right commit with the API.

[herrvigg]

Git Updater assumes that since you tag your releases that the latest tag is the one to use for the download package.

Again, that is not the problem. The problem is the process before download tha assumes the branch of reference is frozen. This doesn't make sense for a master branch, which is the default for git-updater btw. I don't think this issue should be closed.

[afragen]

What do you expect to happen?

What do you see happening?

[herrvigg]

Here is my suggestion, it should be pretty simple:

1) As currently done - API call to find the latest release (nothing to change, thanks for giving the link above) https://api.github.com/repos/qtranslate/qtranslate-xt/releases/latest

2) Look for the tag From the response we expect a tag in the release (I think git requires this). There are two options:

  "tag_name": "3.14.0",
 "html_url": "https://github.com/qtranslate/qtranslate-xt/releases/tag/3.14.0",

3) API or direct HTTP call (?) to fetch the plugin information, not from the latest commit but from the tree given by that tag. Example - note the tree level: https://github.com/qtranslate/qtranslate-xt/tree/3.14.0 From (2) it might be simpler to take the html_url and substitute releases/tag with tree and we're done :)

4) The rest should be as usual, assuming the deployment is still done from the last release.

So thanks to the tag we don't even need to worry about the commit SHA. I guess this shouldn't require much changes, this would improve all the logic of git-updater that is based on the latest release.

[herrvigg]

In fact as a direct benefit, I think this would fix the problem of "update loops" when the plugin version is changed in the working branch, before creating a release. That would give more flexibility to the developers, a nice improvement IMO :)

[herrvigg]

The main philosophy is that git-updater only cares about the git releases. With this you could even remove the concept of required branch as a user parameter? Even if there are multiple lines of versions, the relevant part should be what the developer tick as "the latest release" (there's a checkbox). That should be the only reference extracted by step (1).

[herrvigg]

You are surely aware of it, by default this is checked when creating a git release from a tag.

[herrvigg]

Indeed I don't understand how the "Enable Branch Switching" feature works. Since there's an API call to get the latest release that is not related to any branch parameter, what is the meaning of setting a different branch?

One more advanced feature that could be interesting for developers is to check for the last commit in a given branch. But in that case you would ignore the latest release. It would be a different mode. As I see it

• basic mode: check for latest release (no branch specified)
• advanced mode: specify a branch and check for latest commit.
• other possible mode: specify a tag or commit SHA manually to "freeze a version"

[herrvigg]

Any update or future plan about this? Branches and releases are orthogonal concepts in git. Reasoning with the "last release" should not involve the need for specifying any branch. Conversely, specifying a branch eliminates the need to look at the releases. Both parts are exclusive.