Time for a new release

[andrewnicols]

I realise that you don't really want to do a release until all features are present, but perfect really is the enemy here.

As it stands, this package is not compatible with PHP version 8.2 and above. So if I am writing my own standards for my project which supports 8.2, and I wish to have PHPCompatability as a dependency of my package, I have to use a development version.

For my users to install my package and get the current version of my package, and have yours installed they have to lower their accepted minimum standard to dev because composer does not allow development versions to be installed as dependencies without this.

It would be great if a new version could be released, even if it is not feature complete.

[jrfnl]

I realise that you don't really want to do a release until all features are present

That actually has nothing to do with it. It is about the current sniffs as they are throwing false positives/negatives due to new PHP syntaxes having been introduced.

See my previous answer about this here: #1468 (comment)

You could always try to help to get the release to the finish line ? There is still some 50% of the sniffs which need review... and as this project has absolutely no funding whatsoever, that's a lot of work to be done in my limited spare time.

Closing as previously asked & answered.

[andrewnicols]

Thanks for the answer. That was the issue I had been looking for.

Can I suggest pinning an open issue to the issue stack so that others may find it and then know what help you are after? It's not clear without digging through closed issues.

[jrfnl]

Well, if you want more context, here are some other issues in which I gave extensive answers about the problems PHP 8.0 (and then 8.1 and 8.2) have caused for tokenizer based packages:

• PHP 8.0 Compatibility Timescale #1236 (comment)
• Release a new version #1284 (comment)

Can I suggest pinning an open issue to the issue stack so that others may find it and then know what help you are after?

Unfortunately a project can only have three pinned issues and we already have three issues pinned... 🤷🏻‍♀️

[andrewnicols]

Thanks for taking the time to reply.

Looking through those issues, and the list in #809, it seems that most of the work to move handling to phpcsutils is already complete.

I'm trying to work out from the TODO list on 809 which are the blocking issues which need to address false pos/neg problems. It seems that they all claimed issues - in fact, most re related specifically with the T_NAMESPACE changes. The unclaimed issues don't seem to relate to tokenizer changes at all, though the errors and warnings are arguably going to cause some false negs I guess.

Is there anything I can do to help update these sniffs and prep the 8.0 side of things?

Equally, is there anything we can feed back to the PHP Project, or via the PHP Foundation for future PHP releases to mitigate a repeat of this problem?

[jrfnl]

I'm trying to work out from the TODO list on 809 which are the blocking issues which need to address false pos/neg problems.

#809 is not directly relevant for the release (as that's about adding new detection features mostly).

The sniff review is and there's no ticket for it as nobody has offered to work on that (other than me, new contributors tend to favour wanting to write new sniffs instead of doing the maintenance work) and keeping track of what needs to be done there is not a small thing. I'm working off a spreadsheet myself, which I could convert to a Google sheet or something if so desired.

Ticket #1239 is a ticket which is about the sniff review and which basically contains the action list/status for one column in that spreadsheet....

Ticket #1226 is another one (change in namespaced name tokens), but less relevant for now as that change in PHP ended up being "undone" in PHPCS 3.x and moved to PHPCS 4.0 (for which there is no timeline). We ended up upping the minimum supported PHPCS version to match, which gets us passed the immediate problem with that change.

The spreadsheet is huge - just to give you an impression - this is a partial screenshot:

Is there anything I can do to help update these sniffs and prep the 8.0 side of things?

There definitely is and not just here either. PHPCS itself, for instance, still doesn't support PHP 8.2 DNF types (which breaks sh*t as now suddenly parentheses are allowed in types - most relevant discussion about this is here: PHPCS#3667). Once it is known how this will be solved in PHPCS, PHPCSUtils will also need to be updated for that (which is why I most often make those changes in conjunction and then pull them to both).

The changes for true types for PHPCS itself at least have been made, but still haven't been completely merged (though are already available via PHPCSUtils, which goes to show why creating/adding that was a good move).

There's also still an open PR related to PHP 8.2 readonly classes and the tokenizer change PHP made for that, which I still need to re-review.

And then there are still some problems with match (see PHPCS#3750).

I haven't even started to look at what will need to change in PHPCS itself (tokenizer wise) to support the syntax changes in PHP 8.3 (dynamic class constant fetch, typed class constants, maybe readonly amendments, maybe arbitrary static variable initializers).

Your offer to help is appreciated. If you seriously want to help, we could do a video call session to get you up to speed and discuss how comfortable you are with the various tasks needed and I could possibly assign some of the PHPCompatibility reviews to you ?

Equally, is there anything we can feed back to the PHP Project, or via the PHP Foundation for future PHP releases to mitigate a repeat of this problem?

Yes: stop the incessant adding of new syntaxes just to type a few characters less.., (in favour of stabilizing a little, which sort of is being done in PHP 8.3, though not for lack of trying).

Something like this RFC (property hooks) is already giving me nightmares, especially with adding three variations of the syntax for the same... If that would go to vote and would pass as-is, it will basically break every single sniff which does anything with OO properties and/or OO methods/functions...

I'm on the PHP Internals mailing list and I do speak up when I see problems coming, but as I don't have a vote, there's not that much more which can be done. Though more people speaking up would help I suppose.

[jrfnl]

(sorry for unloading all that onto you, but yes, all of that is on my plate and it's a lot...)

[andrewnicols]

I should be able to arrange a time to catch up and discuss this.

I'm happy to help with maintenance of existing sniffs if you can give me guidance as to which ones need to be looked at and if you have any plans for them already.

We're just in the final few weeks of a release but I should be able to find some time to help move things along in some ways.

[jrfnl]

@andrewnicols Just ping me to set up a call when you have some availability.