You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Is the latest recommended release 2.1.1 or 2.1.2? #526
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?
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
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 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)
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
Activity
stesie commentedon Feb 18, 2024
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 commentedon Feb 19, 2024
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 commentedon Jun 11, 2024
@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 commentedon Jun 12, 2024
@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
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
redbullmarky commentedon May 7, 2026
Closing out in favour of #525 ; ideal next version would be 3.0.0