I do understand your point - though I don't exactly see the problem in this case.

There hasn't been any release (needed?) since December 2017 for the 3.x branch, so chances are there are not going to be many bugfixes required. Again, I'm not proposing to retire 3.x and force everybody to use 4.0 to get fixes.

All I'm saying basically is that when going for a 4.0, we should not restrict ourselves to any old PHP version. We can break BC, can change concepts and, maybe, make use of new syntax features to make the code more maintainable. If that even is the case. If we find, after creating a 4.0 it works fine with 8.0 even, we could simply lower the bar instead of artificially raising it.

The current version says PHP 7.1+.

It won't magically stop working when a 4.0 version of this library is released, regardless of what PHP version that one would require.

Given it's 7.1+, some rule should probably be defined as to how the support should continue - but so far I don't see a direct need to even raise the minimum version per se. It might not get any new features, but that's not expected I guess.

Pretty much what we at PHPUnit call "life support" ;)

I'd be in favor of 8.1, maybe even 8.2.

Given the current composer.json claims compatibility with PHP 7.1+, we should ensure it works either way. Maybe we should restrict the current release to not be that open to newer PHP releases by default. ;)

But if we introduce potentially breaking changes, we can just as well raise the PHP Level to a current version.

All imho ;)

Add forgotten return type

CS/WS

Fix Copy/Paste Error

Implement XML Logfile Format Writer

Update Logfile Schema

Adjust "template" logfile xml to match XSD

Add Usage example code for xml logfile writer

Cleanup cache after install

As requested in https://github.com/phar-io/phive/issues/292#issuecomment-1470137500:

Download

wget https://github.com/maglnet/ComposerRequireChecker/releases/download/2.1.0/composer-require-checker.phar
wget https://github.com/maglnet/ComposerRequireChecker/releases/download/2.1.0/composer-require-checker.phar.asc
wget https://keys.openpgp.org/vks/v1/by-fingerprint/B0906BA775992B910F4E83CBD2CCAC42F6295E7D

Import

mkdir gpg
gpg2 --no-tty --homedir ./gpg --import B0906BA775992B910F4E83CBD2CCAC42F6295E7D

CLI Test

$ gpg2 --no-tty --homedir ./gpg --status-fd 1 --verify composer-require-checker.phar.asc composer-require-checker.phar

Output

gpg: WARNING: unsafe permissions on homedir '/tmp/x3/./gpg'
[GNUPG:] NEWSIG magl@magl.net
gpg: Signature made Sa 28 Dez 2019 14:51:12 CET
gpg:                using RSA key B0906BA775992B910F4E83CBD2CCAC42F6295E7D
gpg:                issuer "magl@magl.net"
[GNUPG:] KEYEXPIRED 1674071325
[GNUPG:] KEYEXPIRED 1674072043
[GNUPG:] KEYEXPIRED 1674071325
[GNUPG:] KEY_CONSIDERED B0906BA775992B910F4E83CBD2CCAC42F6295E7D 0
[GNUPG:] KEYEXPIRED 1674071325
[GNUPG:] SIG_ID i6rvZb5Bq2lNoRKCxrd/8j/81Wc 2019-12-28 1577541072
[GNUPG:] KEYEXPIRED 1674071325
[GNUPG:] KEYEXPIRED 1674072043
[GNUPG:] KEYEXPIRED 1674071325
[GNUPG:] KEY_CONSIDERED B0906BA775992B910F4E83CBD2CCAC42F6295E7D 0
[GNUPG:] EXPKEYSIG D2CCAC42F6295E7D Matthias Glaub <matthias@glaub-online.de>
gpg: Good signature from "Matthias Glaub <matthias@glaub-online.de>" [expired]
gpg:                 aka "Matthias Glaub <magl@magl.net>" [expired]
[GNUPG:] VALIDSIG B0906BA775992B910F4E83CBD2CCAC42F6295E7D 2019-12-28 1577541072 0 4 0 1 10 00 B0906BA775992B910F4E83CBD2CCAC42F6295E7D
gpg: Note: This key has expired!
Primary key fingerprint: B090 6BA7 7599 2B91 0F4E  83CB D2CC AC42 F629 5E7D

PHP Test

var_dump(extension_loaded('gnupg'));

putenv('GNUPGHOME=./gpg');

$gpg = new \Gnupg();
$gpg->seterrormode(\Gnupg::ERROR_EXCEPTION);

var_dump(
    $gpg->verify(
        file_get_contents('composer-require-checker.phar'),
        file_get_contents('composer-require-checker.phar.asc')
    )
);  

Output

bool(true)
array(1) {
  [0]=>
  array(5) {
    ["fingerprint"]=>
    string(40) "B0906BA775992B910F4E83CBD2CCAC42F6295E7D"
    ["validity"]=>
    int(0)
    ["timestamp"]=>
    int(1577541072)
    ["status"]=>
    int(117440665)
    ["summary"]=>
    int(32)
  }
}

I have no idea where the status of 117440665 comes from, the summary of 32 seems to suggest the signature is considered invalid somehow. Which technically seems wrong.

Can certainly do :)

Ping?

Having a standard way to determine whether or not we should use a colored output sounds like a good idea.

This ticket is used to keep track of this idea, as described at https://bixense.com/clicolors/.

It looks like, even after such a long time, neither of the projects listed on the above reference page have opted for implementing this. I certainly haven't seen this variable set in an CI system i use.

I don't think there's any use in implementing support for this particular ENV variable. I might consider adding a better detection whether or not color output is supported. But for now, this is a won't fix.

I just revisited this issue and still can

a) reproduce this with current PHP 8.2.4 + pecl/gnupg 1.5.1 b) have no means of fixing this as it's failing in the pecl/gnupg code somewhere

Trying to involve the pecl/gnupg dev(s) here :)

This is certainly heading in the right direction.

I'm still having a few smaller issues though. I'm not sure if all got introduced by your changes or have been there to begin with and now only became more obvious. ;)

I'll be heading to Montreal for Confoo tomorrow and maybe I'll have some time on the flight to review things a bit more in depth.

I generally like the idea of decoupling the actual (global) Facade from the individual classes using them - while this PR of course only addresses the registration of Subscribers or Tracers and not the emitting of events.

I have two problems with the implementation this PR proposes:

• I don't like the implicit "protocol" of having to know that one has to manually call the registration
• I seriously dislike the array return type as it's generic and not providing any type safety

Maybe we can fix these problems somehow?

Fixed in 1.27.2.

Update changelog for Release 1.27.2

Make code run under <7.4

When I run phpab on PHP 8.2, I get a deprecation warning:

[spriebsch@spriebsch master-coder]$ php -v PHP 8.2.2 (cli) (built: Jan 31 2023 13:31:55) (NTS gcc x86_64) Copyright (c) The PHP Group Zend Engine v4.2.2, Copyright (c) Zend Technologies with Xdebug v3.2.0, Copyright (c) 2002-2022, by Derick Rethans

[spriebsch@spriebsch master-coder]$ tools/phpab -o src/autoload.php src PHP Deprecated: Creation of dynamic property TheSeer\Autoload\CLI::$outputOption is deprecated in phar:///home/spriebsch/thephpcc/master-coder/tools/phpab/phpab/CLI.php on line 362 PHP Stack trace: PHP 1. {main}() /home/spriebsch/thephpcc/master-coder/tools/phpab:0 PHP 2. TheSeer\Autoload\CLI->run() /home/spriebsch/thephpcc/master-coder/tools/phpab:157 PHP 3. TheSeer\Autoload\CLI->setupInput() phar:///home/spriebsch/thephpcc/master-coder/tools/phpab/phpab/CLI.php:82 PHP Deprecated: Creation of dynamic property TheSeer\Autoload\CLI::$lintOption is deprecated in phar:///home/spriebsch/thephpcc/master-coder/tools/phpab/phpab/CLI.php on line 472 PHP Stack trace: PHP 1. {main}() /home/spriebsch/thephpcc/master-coder/tools/phpab:0 PHP 2. TheSeer\Autoload\CLI->run() /home/spriebsch/thephpcc/master-coder/tools/phpab:157 PHP 3. TheSeer\Autoload\CLI->setupInput() phar:///home/spriebsch/thephpcc/master-coder/tools/phpab/phpab/CLI.php:82 phpab 1.27.1 - Copyright (C) 2009 - 2023 by Arne Blankerts and Contributors

Scanning directory src

Autoload file src/autoload.php generated.