Version that doesn't throw deprecation warnings in 8.1 but works in 8.0?

[iansltx]

I realize I'm coming in on the tail end of this discussion, but is there any reason that 5.x couldn't work with PHP 8.0? Right now you can either use 3.x, which throws a bunch of deprecation warnings in 8.1, or 5.x, which is incompatible with 8.0, so there's no way to set up a codebase using Aura.Sql that'll run cleanly on both. Ideally I want to make all the code changes I need for forward compat under 8.0, then when 8.1.1 is released the only thing I have to do is update our Dockerfile base and push the result out to prod.

If there's a technical reason Aura.Sql 5.x can't work with 8.0, and I just missed it, fair enough, but figured I'd ask so others don't have to.

[kenjis]

Thank you for your question.

It is the policy of Aura Project.

• The Aura 3.x series was for PHP 5.6 and later.
• The Aura 4.x series is for PHP 7.2 and later.
• The Aura 5.x series is for PHP 8.1 and later.

See #192 (comment) and auraphp/Aura.Cli_Kernel#12 (comment)

[iansltx]

...but Aura.Sql doesn't have a v4.x branch, or did I miss something? I did see the "are you okay with 8.1" "sure, go ahead" comment as I was checking into this, though I hadn't seen the earlier comment you linked here, where @pmjones was unsure of whether to target 8.0 or 8.1.

On initial scan, I didn't see anything that would prevent 8.0 compat. If other folks aren't averse and the lift is relatively low (a few hours), happy to make tweaks needed to ensure compat with both 8.0 and 8.1, since that would let us be warning-free on both 8.0 (which we run now in prod) and 8.1 (which we'll run as soon as 8.1.1 comes out).

For what it's worth, Aura.Sql is the only lib that has this hangup.

[kenjis]

5.x requires "php": ">=8.1", so you can't install on PHP 8.0 even if it is compatible with 8.0.
It seems you need 4.x branch that requires "php": ">=7.2".

[iansltx]

Is there a 4.x release of Aura.Sql?

I realize that composer.json has the hard version requirement of ^8.1. if it didn't I wouldn't have raised an issue. I would've just installed it :)

[kenjis]

Is there a 4.x release of Aura.Sql?

No. When we need it, we create it.

[iansltx]

If I created a PR for 5.x that passes all tests on 8.0 as well as 8.1, would y'all merge, or would I need to run a fork at that point?

[iansltx]

Alternately, if I figured out a way to get compat with 7.2-8.1 on Aura.Sql without deprecation warnings, would y'all be amenable to tagging that as 4.x, providing a bridge from 3.x (5.6-8.0) to 5.x (8.1+)?

[kenjis]

I don't oppose to create 4.x for PHP 7.2 - 8.1.

5.x dropped support of PHP 8.0. It means we can use all PHP 8.1 functionality.
Making 5.x 8.0 compatible is non sense for me.

[iansltx]

Got it; will see what I can do here for 7.2-8.1 compat.

[iansltx]

Took maybe an hour and 20 to drop enough 7.3+ features to get things to run, plus adding the annotations needed to bridge without deprecation warnings, but we now have an Aura.Sql version, based on the 5.x branch (so, as many enhancements from that branch as possible), that passes with no deprecation warnings from PHP 7.2 to PHP 8.1. So now folks (ourselves included) have a bridge version that we can deploy today on 8.0 that we can run on 8.1 as well (and then upgrade to 5.x later):

https://github.com/iansltx/Aura.Sql/tree/4.x

Let me know what needs to happen to promote that branch upstream.

[kenjis]

@iansltx Thank you for your effort!

I've created 4.x branch from 5.x.
Now you can send a PR.

[pmjones]

Gotta say I'm impressed by the teamwork here. Nicely done!

[koriym]

The 3.x code that @pmjones created in 2015 still gets the job done today, people just need it to work in a latest PHP environment.

"can use all PHP 8.1 functionality." Do we need it? I have slightly mixed feelings about dropping PHP 8 support in 5.x and more branches with almost the same content.

[iansltx]

I will say that, if I had just needed to drop 8.1 only functionality rather than 7.3-8.1, my job would've been easier. And 8.0 support would've been enough to allow for a smooth transition from 3.x to 5.x, which is excellent for a version that has been around for six years and crossed two major PHP releases compat-wise.

But I basically said that earlier :)

[koriym]

I'm sorry if I sounded rough. It's certainly great to see various people contribute in this way to solve the problem.

[kenjis]

"can use all PHP 8.1 functionality." Do we need it?

It is dangerous question. It might kill ourselves. ;-)

But many developers should love 8.1, and want to use it.
8.1 seems to be really good!
https://www.php.net/releases/8.1/en.php

[iansltx]

I was asking what functionality in 8.1.Aura.Sql v5 used. The answer appears to be "PDO returning integers" and nothing really else?

[kenjis]

According to the PHP manual, changes on PDO are:

• https://www.php.net/manual/en/migration81.new-features.php#migration81.new-features.pdo_mysql
• https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.pdo
• https://www.php.net/manual/en/migration81.deprecated.php#migration81.deprecated.pdo
• https://www.php.net/manual/en/migration81.other-changes.php#migration81.other-changes.functions.pdo-odbc

[iansltx]

Closing this as 4.x covers 7.2-8.1.