Prepare release 0.9.9 (part of #255)

[hartwork]

Part of #255

CC @kocsismate @TimWolla

[TimWolla]

cc @remicollet for php/php-src#18886

[TimWolla]

@hartwork I have a last minor request related to my previous comment in this issue: Would it be feasible to add a new uriVerA() function to allow retrieving the library version at runtime instead of build time?

From what I see, you are taking great care of ABI compatibility, which makes it easy to update the library version without recompiling PHP. For PHP's phpinfo output it would be useful to have both the version that PHP was compiled against as well as the version actually used (e.g. when a bug is fixed in a future version of the library).

See also: php/php-src#19678

[hartwork]

@TimWolla are you aware that because of security backports in distros runtime version information is often not accurate and would need to be read as "that version minimum plus an unknown amount of security fixes on top"? I have rejected a previous request for adding runtime version at #219 (comment) because of that. Simplified it cannot be be relied upon and then what is the value? With that said, does it change the picture for you with PHP?

[TimWolla]

Yes, I'm aware that distros often backport patches to older versions, but as part of that they generally modify the version number in some way. I would expect the distros to patch the library in a way that this kind of difference is detectable, e.g. by setting URI_VER_SUFFIX_ANSI. Debian 11 for example has 0.9.4+dfsg-1+deb11u1 as the full version, with deb11u1 indicating that this is the first backport release for Debian 11 (see https://tracker.debian.org/pkg/uriparser). Given that the function would only return a char*, the guarantee provided would be “a version string for human consumption” (i.e. not meant to work around bugs programmatically, but just as additional information for the human when someone is seeking support).

[hartwork]

Yes, I'm aware that distros often backport patches to older versions, but as part of that they generally modify the version number in some way.

@TimWolla yes and no: The version of the packaging is bumped, yes, but in many cases the runtime identification remains at the base version despite security fixes.

I would expect the distros to patch the library in a way that this kind of difference is detectable, e.g. by setting URI_VER_SUFFIX_ANSI. Debian 11 for example has 0.9.4+dfsg-1+deb11u1 as the full version, with deb11u1 indicating that this is the first backport release for Debian 11 (see https://tracker.debian.org/pkg/uriparser). Given that the function would only return a char*, the guarantee provided would be “a version string for human consumption” (i.e. not meant to work around bugs programmatically, but just as additional information for the human when someone is seeking support).

We're in interesting territory here, because "at least version X" maybe still has more value than no information. Maybe mixing up "exact version" and "minimum version" can be help to some extent. What if we have a function uriMinimumRuntimeVersion that returned string 0.9.9+ or >=0.9.9 to be crystal clear that it's nothing but a minimum?

[TimWolla]

What if we have a function uriMinimumRuntimeVersion that returned string 0.9.9+ or >=0.9.9 to be crystal clear that it's nothing but a minimum?

That would likely work for PHP's use case. To showcase how it will look like:

and on the CLI:

uri

uri support => active
uriparser library version => 0.9.8

This is what we currently have on the phpinfo(); output. I would probably split this into “compile time version” and “runtime version” to show both of them:

uri

uri support => active
Compiled against uriparser => 0.9.8
Running with uriparser => 0.9.9+

Distros would still be able to appropriately patch uriMinimumRuntimeVersion() to provide additional information if the expected guarantee by the function is “a string for human consumption”.

[hartwork]

That would likely work for PHP's use case.

@TimWolla alright, let me do the 0.9.9+ version…

[hartwork]

@TimWolla I became aware that the "+" suffix assumed additions when in fact distributors could also cut away functionality where it would be misleading. So I discarded the addition of "+". Pull request #258 is ready for review, if you have a minute 🙏

[TimWolla]

Thank you!

[kocsismate]

Thanks!

[hartwork]

Glad I could be of help! 🙏