Minimal supported PHP version

[remicollet]

package.xml states 5.3.7

But 6d993db9347edf623cca6048e25a65a0b5a9a9ab breaks support for 5.x

I don't think it makes sense to keep support for so old EOL version

Which solution?

• restore 5.x compatibility ?
• raise the minimal supported version to 7.0
• raise the minimal supported version to 7.4 ? or 8.0 ? and clean the sources of most/all the conditions on PHP_VERSION_ID

[eduardok]

Well, PHP 7.3.33 (last one) was released 3 years ago, and 7.4.33 2 years ago, so it would probably make sense if we cleaned up PHP_VERSION_ID conditions < 7.4. We could simply note on the README that 1.1.1 was the last one supporting PHP 5.x, perhaps also add a tag.

[remicollet]

so it would probably make sense if we cleaned up PHP_VERSION_ID conditions < 7.4.

+1

P.S. and probably bump version to 1.2.0-dev

[eduardok]

Well, now seeing that PECL doesn't like the dash in -dev I'm wondering if we even need -dev since it is really stable considering the changes are simply deletes, see https://github.com/eduardok/libsmbclient-php/tree/php74 . So we'd simply have this and be done:

-        <min>5.3.7</min>
+        <min>7.4.0</min>

[remicollet]

Well, now seeing that PECL doesn't like the dash in -dev

Usage is 1.2.0-dev in code but 1.2.0dev in package.xml

Ex: https://github.com/php/pecl-mail-mailparse/commit/f73ef80fd4acd8b69f1a463b61babcf509179a7a

[mlocati]

I wonder how it is possible that when my script has problems with PHP extensions and I look for a reason/solution, I always see @remicollet who has provided a solution a few hours earlier 😍

[eduardok]

Well, now seeing that PECL doesn't like the dash in -dev

Usage is 1.2.0-dev in code but 1.2.0dev in package.xml

Ex: php/pecl-mail-mailparse@f73ef80

Anyway, got it published...

[remicollet]

I don't understand why you tag/publish this release

"dev" is only a git state

• 1.2.0dev => devel in git
• 1.2.0alpha1 / 1.2.0beta1 / 1.2.0RC1 => beta release
• 1.2.0 => stable release
• 1.2.1dev => back to devel, in git

[remicollet]

Especially as 1.2.0dev states it is a "stable" release

# pear list-upgrades
pecl.php.net Available Upgrades (stable):
=========================================
Channel      Package   Local          Remote            Size
pecl.php.net smbclient 1.1.2 (stable) 1.2.0dev (stable) 35kB

Please retire this release

[eduardok]

That all illustrates what I meant in the beginning... https://pear.php.net/manual/en/guide.developers.package2.stability.php refers primarily about the API being stable and the code not being new. All I removed were ifdefs, so the API hasn't changed and the code is very stable, as usual. So 1.2.0 made sense to me given the drop of older PHP versions, but that's about it, didn't really see a reason for -dev. To me it's like 1.2.0 can be released as stable.

[eduardok]

Anyway, considering the respect I have for all the work you've been doing for many years, give it some thought and let me know what is your final preference, then I will make the necessary changes.

[remicollet]

Sorry, I was probably confusing when I say "... bump version to 1.2.0-dev ..."

This was because dropping support for old versions, but only for "git" sources, as this is a common practice to keep the dev suffix in git during development (also to identify in bug report people building from sources from git/master)

Of course, this suffix has to be dropped before release.

Ex of this common workflow in the xpass extension (git always has dev suffix, release don't)

• Release 1.0.0 tagged and published on pecl
• back to dev immediately after the release (also fill changelog, and empty notes for next release)
• version bump because new API
• Release 1.1.0RC1 pre-release tagged and published
• Release 1.1.0 new tag
• back top dev immediately after the release