wpackagist
wpackagist copied to clipboard
outlandishideas
Trunk is installed rather than tag for advanced-post-manager
You'll see they don't keep any code in trunk: https://plugins.trac.wordpress.org/browser/advanced-post-manager/#trunk
But there are tags with full code: https://plugins.trac.wordpress.org/browser/advanced-post-manager/#tags/4.5.0
If I specify in my composer.json "*" or "4.5.0" it installs from trunk.
Looking in ~/.composer/cache/repo/https---wpackagist.org/provider-wpackagist-plugin$advanced-post-manager.json I see there is an entry for 4.5 (normalized to 4.5.0.0.) pointing to trunk, and then also a 4.5.0 (also normalized to 4.5.0.0 pointing to the correct dist/zip).
Does wpackagist look at the readme.txt for versions at all? Because trunk specifies Stable tag: 4.5.0 while tag 4.5.0 specifies Stable tag: 4.5. Maybe this has something to do with it.
The same goes for enlighter it seems. Here everything seems to be at 4.2.0 except for the plugin itself (enlighter.php file).
https://wpackagist.org/p/wpackagist-plugin/enlighter%24ebf508e505ec8f47198e73a96b602b85731dd1c4dd2ae648ddc0b7f8b57c4452.json
https://plugins.trac.wordpress.org/browser/enlighter
Edit: I just found out where it goes wrong for the enlighter plugin: https://github.com/outlandishideas/wpackagist/blob/master/src/Command/UpdateCommand.php#L117
The $info['version'] is the version from the plugin's php file. Where the other versions are the svn tags. The version in the php file doesn't match any of the tags and therefore it set's the current "wordpress" version to trunk.
I think this is a live issue, but as you suggest is down to the published package data not being self-consistent in this particular case. I'm not sure the complexity of parsing versions differently to work around this is necessarily worth it but I'm definitely open to PRs if they can address this without significantly slowing down the update process.
