v5 release plans

[weirdan]

I'd like to kickstart the discussion about Psalm 5 release. I'm expecting this to be mostly between maintainers (ping @orklah) but other regular contributors are also welcome to chime in.

Dev availability

I'll be able to put in some hours (more than usual) in the beginning of January.

Branching strategy

I propose to branch 4.x, and set it as default branch until v5 is released. This will open master for breaking changes. Changes in 4.x would be regularly merged up to master.

Changing default branch would require @muglug's help.

EOL timeline

This is an open question really: how long do we intend to support 4.x, if at all?

PHP version bump

Not sure. We still have up to 10% downloads from hosts running 7.3 (https://packagist.org/packages/vimeo/psalm/php-stats#4), but I think we should bump to at least 7.4.

Callmap versions

Personally I don't think we should drop any callmap deltas, unless it becomes a maintenance burden. It doesn't feel like a burden to me at the moment.

Actual BC breaks

Most breaks that we want to do are either marked in the code comments (grep 'Psalm 5') or already have PRs open.

Upgrade documentation

Should we have any, where we explain things that changed in plain English, as opposed to just listing them?

[muglug]

Happy to help with default branch changes!

For the version change is there a pressing reason (a dep requiring a higher version, for example)? I think it might make sense to go to 7.3 again. In May 2019, the last time dependencies were shifted, 81% of packagist users had a compatible PHP version.

If we shifted to 7.3 today that would be about 88% of the current packagist userbase. If we moved to 7.4 it would be about 76%. I would vote for 7.3 — I know it's not ideal, but as dev tool-makers I think it's good to have as wide compatibility as long as doing so doesn't sacrifice our sanity or project maintainability.

[weirdan]

For the version change is there a pressing reason (a dep requiring a higher version, for example)?

webmozart/path-util was deprecated in favour of symfony/filesystem:>=5.4, and that requires PHP >=7.2.5. Other than that there are no pressing reasons due to dependencies.

[orklah]

how long do we intend to support 4.x, if at all?

I believe PHPStan has a pretty restricted policy about maintenance on old version and it seems to work well (every user is encouraged to use the latest version at any time). However, they still support 7.1 so there is no excuse from user not to upgrade. This will likely not be our case.
I think big regressions from recent versions should be fixed if we happen to discover some (say for a month or two probably?), but no other bug fix should be fixed on older versions IMHO.

I think we should bump to at least 7.4.

I agree on that. We saw recently bugs related to the php version used to run psalm (mainly because of reflection). The wider range we support, the more we'll have issues with that.
Furthermore, we're starting to see dependency issues and it's likely it will not get better as time pass.
Psalm 4 was already scheduled to drop PHP 7.2 support, dropping 7.3 more than a year later seems fine.
We should keep in mind that user who absolutely want to stay on EOL php versions will still be able to use Psalm in V4

Personally I don't think we should drop any callmap deltas

Yeah. current target for lowest callmap is 7.1. It's not unreasonable to assume that a lot of projects still runs Psalm in this version, or even lower. Due to the nature of Psalm, a project in 7.1 is all the more likely to need this tool even more.
Except for a few keywords that were reserved in 7.2, there is not a lot to gain to shift everything to 7.2 and we're even likely to keep it that way for the next major (dropping PHP 7 on a whole would start really making a difference, but it's not even remotely possible for the next few years)

[muglug]

OK — if you're both in favour of 7.4 then go for it! That means arrow functions and a few other nice things (though I think the performance issues with typed properties maybe rules that particular migration out for hot paths).

The only other thing I'd say is there's no reason why 7.4 has to accompany a major version change — I think it's perfectly ok to do it midway through a version (WordPress adopted that sort of program — their bump from PHP 5.2 to 5.6 didn't accompany a major version increase).

Maybe you could update to 7.3 now, signalling your intent to upgrade to 7.4 in early 2022 so the still-on-7.3 laggards aren't caught off-guard and can plan their own migrations. I'm also wary that PHPStan still only requires PHP 7.1 — there's no need to annoy people into jumping ship.

[orklah]

Honestly, I'm not too worried that the few people using 7.1 to 7.3 will be:

• annoyed not to be able to use the latest and shiniest version of Psalm(V4 is perfectly usable and stable, especially for older php versions)
• unwilling to consider setting up a CI running on a more recent version of PHP
• willing to make the change to phpstan out of annoyance

all at the same time!

About version bumps, I have no issue in principle, but what worries me the most is that we'll find regressions in the weeks following the new major that we'll have to fix.
This means that if we bumped the php version in a minor, we'll have to fix the issue:

• for the minor in the oldest php versions
• for the minor containing the bumped php version
• for the major

[weirdan]

I think the performance issues with typed properties maybe rules that particular migration out for hot paths

Are there any public benchmarks? I recall the RFC boasting about very low performance impact, in order of couple percent points.

[weirdan]

Quick update: all BC breaking PRs have been merged to master.

[weirdan]

What are your thoughts on automated upgrades using https://github.com/rectorphp/rector? I tested it on a small subset of files (src/Psalm/Type), and it produces decent results, much better than they make it sound in their README.

[weirdan]

This is the list of rectors rector identified as applicable:

$ vendor/bin/rector process --output-format=json --dry-run | jq -r '[.file_diffs[].applied_rectors]|flatten|unique'
[
  "Rector\\Php56\\Rector\\FunctionLike\\AddDefaultValueForUndefinedVariableRector",
  "Rector\\Php70\\Rector\\FuncCall\\RandomFunctionRector",
  "Rector\\Php71\\Rector\\List_\\ListToArrayDestructRector",
  "Rector\\Php73\\Rector\\FuncCall\\JsonThrowOnErrorRector",
  "Rector\\Php73\\Rector\\FuncCall\\StringifyStrNeedlesRector",
  "Rector\\Php74\\Rector\\Assign\\NullCoalescingOperatorRector",
  "Rector\\Php74\\Rector\\Closure\\ClosureToArrowFunctionRector",
  "Rector\\Php74\\Rector\\FuncCall\\ArraySpreadInsteadOfArrayMergeRector",
  "Rector\\Php74\\Rector\\LNumber\\AddLiteralSeparatorToNumberRector"
]

I manually excluded the following rectors:

    $services->remove(StringClassNameToClassConstantRector::class); // produces unwanted results
    $services->remove(TypedPropertyRector::class); // risky
    $services->remove(CountOnNullRector::class); // buggy

[orklah]

I'm all for it, it's basically psalter :)

we should probably do one PR per change, it will be easier to review

[weirdan]

All interesting rectors are applied now. #7319 is blocked by #7296

[tm1000]

@weirdan @orklah FYI I am working on an upgrade to the LSP server for better performance. I'm currently using it in my day-to-day work as I improve it and then I'll let me co-workers use it too. I want to implement this into v5 but also I'm intent on it not being a breaking change to how anything works currently

See: https://github.com/vimeo/psalm/compare/4.x...tm1000:feature/upgrade-lsp?expand=1

This is not finished and I have not even drafted it into a PR yet

[pkly]

Since no new features (eg. intersection types) are being added is there a proposed release date for psalm 5?
Ever since upgrading to 8.1 we're kinda stuck, since we want the added type safety of intersections, but psalm just outright quits in v4...

[pkly]

I'm not sure if the plugins we use (doctrine and symfony) are available for v5, but seeing how regardless of it they are we couldn't use psalm atm it matters little.
I could set up master to be used for our 8.1 project and hopefully submit any feedback I have, but that project is a smaller one, so it's likely there won't be that much of it.

However our main project is nearing a 8.1 upgrade, so I could look into implementing it there then as well.

I would also like to say that I greatly appriciate all the work you and other contributors put in, as psalm is a truly great tool (even if sometimes it annoys the heck out of me). We've solved more than 1k+ potential issues thanks to you.

[muglug]

@orklah I've done what I can to get master updated!

[orklah]

Awesome! Thanks!

[M1ke]

FWIW I've put psalm5 into one of our pipelines now. So we'll be testing on 4 and 5 as standard for a while, will let you know if any significant divergence (or at least, if those are problematic rather than just finding new stuff in 5 because it's better)

[orklah]

I've just released a beta version which will be more up to date for your CI :)

@muglug do you mind communicating on the release through the twitter feed?

[M1ke]

Seen that, it includes my fix for thread limit too, which has currently broke the alpha on our CI anyway. I'll bump to beta 1 on Monday, am now done with work and having a well earned drink - zum wohl!

…

On Fri, 13 May 2022, 8:37 pm orklah, ***@***.***> wrote: I've just released a beta version which will be more up to date for your CI :) @muglug <https://github.com/muglug> do you mind communicating on the release through the twitter feed? — Reply to this email directly, view it on GitHub <#7171 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJLLC2ZTZIGJ766ECBWL6LVJ2VQFANCNFSM5KEZLB6A> . You are receiving this because you commented.Message ID: ***@***.***>