Is the latest recommended release 2.1.1 or 2.1.2?

[ryandesign]

2.1.2 is the latest tag in this repository and it is listed as a stable version on pecl, however on the main page of this GitHub project 2.1.1 is listed as the latest release. Is this an oversight (if so, please fix) or is there a reason why 2.1.1 should be preferred over 2.1.2?

[stesie]

After all that's an oversight ... and to be honest, likely you don't want to use neither of these these days.
The 2.x.x line targets PHP 7.x, and since it has no security support any longer, you likely don't want to use it.

So currently I'd recommend to build from "php8" branch. Unfortunately we haven't had a release for quite a while. Hopefully however that's soon a thing of the past, we already have #525 as a task, and the idea is to finally release in the next days.

Regarding 2.1.2, I'm hesitant to create the release on GitHub now, since it'll then tell that it was released today - and that would be very misleading. And seems like there's no way on GitHub to backdate a release

[ryandesign]

Congratulations on your upcoming new release! I still think it's a good idea for all of your releases to be listed on your releases page, even belatedly. I too am irritated that GitHub doesn't allow releases to be backdated. You could indicate in the release text what the correct release date is. If you want to avoid drawing attention to an old release when a new one is imminent, you could create the 2.1.2 release right before you create the 3.0.0 release.

[dinamic]

@stesie it'd be great if we could have a PHP 8 compatible version released and even more so in PECL.

Is there something we could contribute to speed things up?

[stesie]

@dinamic if you'd like to help out on #525 that would be great and very much appreciated :)

I think what we have to do at least is

• update package.xml, in there include a "changelog" for this new version (and update the file list including hash sums - okay, that one should be done last obviously)
• update minimum supported version in README; needs test compilations (or go the opinionated route, pick some moderately old version, test that and list it)
• I think we still need a PR for Compilation error: "no matching function for call to 'v8::ObjectTemplate::SetAccessor" #528

apart from that, maybe someone want's to work on the lib/include file lookup, there's some frustration coming up here and there, that it should be different, see #522. Possibly also add/update some notes in the README