Full semantic versioning string is not used within plugin metadata fields

[roy-bongers]

I'm using composer and wpackagist to install plugins. The 4.2 install breaks the plugin. Only a single readme.txt file is installed.

This is the diff of my composer.lock file when updating to 4.2

         {
             "name": "wpackagist-plugin/enlighter",
-            "version": "4.1.0",
+            "version": "4.2",
             "source": {
                 "type": "svn",
                 "url": "https://plugins.svn.wordpress.org/enlighter/",
-                "reference": "tags/4.1.0"
+                "reference": "trunk"
             },
             "dist": {
                 "type": "zip",
-                "url": "https://downloads.wordpress.org/plugin/enlighter.4.1.0.zip"
+                "url": "https://downloads.wordpress.org/plugin/enlighter.zip?timestamp=1588186369"
             },

I think some SVN tag was not pushed because reference is now trunk instead of tags/4.2.0 as I would expect. Or maybe the version should be "4.2" instead of 4.2. When I download https://downloads.wordpress.org/plugin/enlighter.4.2.0.zip I get the correct version.

[AndiDittrich]

i'm not using wpackagist

the trunk branch is not used by Enlighter and should never be used to reference releases - your composer.lock generation seems to be broken

[roy-bongers]

Just did some more research. This is the file where the 4.2(.0) version specification is located: https://wpackagist.org/p/wpackagist-plugin/enlighter%24ebf508e505ec8f47198e73a96b602b85731dd1c4dd2ae648ddc0b7f8b57c4452.json

It doesn't matter if I lock the version to "4.2.0" or "4.2" in the composer.json file. Only the trunk version is installed. My guess is that there is some incompatibility with the versioning. I see the svn tag is also "4.2.0" but the plugin version is "4.2".

[AndiDittrich]

the plugin version is 4.2.0 - the issue is caused by wpackagist...it is not Enlighter related.

[AndiDittrich]

just FYI:

WordPress trunk (stable tag points to 4.2.0) - https://plugins.svn.wordpress.org/enlighter/trunk/readme.txt

WordPress tag/4.2.0 - https://plugins.svn.wordpress.org/enlighter/tags/4.2.0/

everything works like expected

[roy-bongers]

I totally agree. The probleem seems to be with wpackagist. At first I thought there might be some versioning issue which prevents this from happening but everything seems totally fine. I hope wpackagist fixes this.

@AndiDittrich Just did some research in the wpackagist code to find out where it goes wrong. The version defined in the plugin file (4.2) does not exist as a svn tag. Because of this the 4.2 composer version is created with "trunk". Would the plugin version match the tag version (both 4.2.0) this problem wouldn't occur.

This is where the logic is located: https://github.com/outlandishideas/wpackagist/blob/master/src/Command/UpdateCommand.php#L117

I just went through the previous releases of enlighter and before 4.0.0 the version in the plugin file always matched the tag. From version 4.0.0 the last digit is missing from in the plugin file. If it's not a problem for you I'd like to ask if you can match the plugin and tag version. It would solve this issue for everyone that uses wpackagist.

I did also mention this in one of the open wpackagist issues so let's hope it get's fixed.

[AndiDittrich]

i can't identify where the plugin is using 4.2 - all tags/version numbers are following the semantic versioning scheme (auto generated code).

if this setting is wrong...everything WordPress.org repository would crash...

[roy-bongers]

I'm sorry I wasn't very clear. I meant these two lines. These lines make that Wordpress.org shows "4.2" and not "4.2.0". https://github.com/EnlighterJS/Plugin.WordPress/blob/v4.2.0/Enlighter.php#L6 https://github.com/EnlighterJS/Plugin.WordPress/blob/v4.2.0/Enlighter.php#L19

wpackagist fetches the plugin details (basically the whole comment section around line 6) and the other available versions (SVN tags). So it fetches 4.2 from the plugin docs and the rest from the SVN tags (3.8, 3.8.1, 3.9.0, 3.10.0, 3.11.0, 4.0.0, 4.1.0, 4.2.0). Since 4.2 isn't in the SVN tags it get mapped to trunk. I'm not an SVN user but it seems trunk is to SVN what master is to git. In that case it would actually make sense to map the latest version to trunk if there is no tag with the same version as specified in the php file.

So if the plugin docs / version are 4.2.0 instead of 4.2 wpackagist doesn't do the default mapping to trunk and we'll get the correct zip file for version 4.2.0.

[AndiDittrich]

oh f*ck.... thanks for that hint!

internally the WordPress.org repo doesn't take much care of the php files...it just extracts the metadata from the readme.txt to point the current release.

i'll update the svn tag itself (i know that's a very bad practice..) asap

[AndiDittrich]

well...that didn't work as expected...the WordPress repo handles it as "new release" it will be fixed with v4.3