Outdated tags for `iwp-client`

[codepuncher]

The latest tag for iwp-client in WP plugin repo is 1.9.4.8.2, however, it is not shown on here https://wpackagist.org/search?q=iwp-client

It's been a few hours now since I've noticed this so I would have thought if it were just waiting for an update it would have happened already.

Is there an issue preventing the tag from being published to WordPress Packagist?

[NoelLH]

@codepuncher I've had a quick look at the version parser in the Composer 1.x class we use for this purpose. I think that even for non-semver cases it only supports up to 4 numeric parts in its normalize().

It seems like when a version number can't be normalised, we currently skip it silently – this isn't ideal and we should probably add some info logs to help validate and track what's happening here – but it suggests the simplest immediate fix would be to convince the plugin's maintainer to use a more standard versioning approach if possible.

I am hesitant to have our supported version formats diverge from Composer's as there's a surprising amount going on in the method I linked, and I don't know if this would also risk Composer itself behaving strangely when determining the correct version to install. I suspect the CLI might well struggle to use these numbers if we were to publish them as Composer metadata, since it would likely expect the same normalisation logic to be followed.

[codepuncher]

@NoelLH yep, that's all completely understandable.
Given that Composer is, well, the standard for dependency management in PHP, doesn't seem that this needs to be fixed surrounding that.
More logging would be good; but would that be of any benefit for a user of WPackagist like myself? Is there a place that we can see these logs anyway? Would save future issues being opened on this repo that are like this issue and users would be advised to contact the package authors directly for the solution.

I have reported the issue to IWP themselves and linked this issue to them for further clarity.
We'll see how it goes and I'll update the issue if needed.

Thanks again.

[NoelLH]

Thanks for the update @codepuncher. The logs stream to our AWS account so I don't think there is a way to expose them that would be worth the effort – my thinking with the info log would just be to dramatically speed up the investigation time if this happens again, particularly if someone else who's not seen this before follows up on a new GitHub issue.

It's not that common so I think if there was something obvious that showed up when we search the logs, the overhead in following up would be fairly minimal. Digging into the number normalisation from cold just took me a bit longer than it needed to because we move on silently without logging.