Prepare 1.5.0 release

[mcdruid]

Note to self: looks like a combination of:

https://pear.php.net/manual/en/developers.release.validating.php

https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

[ashnazg]

If it would help, I can roll the release and document all the steps for you... just let me know.

[mcdruid]

Thanks @ashnazg, I'm happy to have a go at this myself but will shout if I get stuck (and appreciate the offer).

Are there any non-obvious steps you think I might miss?

I was thinking I need to prepare package.xml for the pear release, then create a github release.

I've yet to find what looks like a single source of truth for the pear release, but (along with the link above about validation) there's:

https://pear.php.net/manual/en/developers.recommendations.releasenotes.php

https://www.electricmonk.nl/log/2009/04/12/easy-pear-package-creation/ looks good for some general context but may not be directly applicable here for creating a new release of a long-standing existing package.

[mcdruid]

Also checking https://pear.php.net/manual/en/developers.php

[mcdruid]

Validating the existing package.xml we get 3 warnings:

$ pear package-validate package.xml
Analyzing Archive/Tar.php
Warning: in Tar.php: function "gzseek" not prefixed with package name "Archive_Tar"
Warning: in Tar.php: function "gztell" not prefixed with package name "Archive_Tar"
Warning: in Tar.php: function "gzopen" not prefixed with package name "Archive_Tar"

This is because of the shim for a 2011 php packaging bug added in #8

It'd be good to avoid these warnings, but I don't see a simple way of doing so as the validator is based on parsing the source file with https://www.php.net/manual/en/function.token-get-all.php and doesn't allow for specific checks to be disabled a la phpcs, for example. It doesn't matter that the functions are only defined conditionally.

I think we could possibly edit the package.xml file to explicitly declare that it provides these global functions, but that doesn't seem like a good solution to me.

There's an argument for removing this shim completely; it seemed to mostly affect ubuntu PHP 5.x in a release which is long since End of Life. Symfony's polyfill had a very similar shim but removed all support for PHP 5 a few years ago. I think https://github.com/symfony/polyfill/blob/v1.19.0/src/Php56/bootstrap.php#L32 was the last tag it appeared in.

Perhaps it'd be better to deprecate the shim and mark it for removal in a future release. I'll file a separate issue for that.

[mcdruid]

@ashnazg if you have the time and inclination to prep a new release and note down the basic steps, I'd appreciate it.

I'm not sure if hand-hacking the package.xml file is the way to go, but have not had much luck trying to install and then use what looks like it might be the appropriate tooling e.g. PEAR_PackageFileManager(2) ?

[ashnazg]

@mcdruid , I got the 1.5.0 release out. I'll be sending you some good release instructions in an email shortly.