Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimal supported PHP version #106

Open
remicollet opened this issue Nov 26, 2024 · 11 comments
Open

Minimal supported PHP version #106

remicollet opened this issue Nov 26, 2024 · 11 comments

Comments

@remicollet
Copy link
Contributor

package.xml states 5.3.7

But 6d993db 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
Copy link
Owner

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
Copy link
Contributor Author

remicollet commented Nov 27, 2024

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
Copy link
Owner

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
Copy link
Contributor Author

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

@mlocati
Copy link

mlocati commented Nov 28, 2024

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
Copy link
Owner

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

pecl-version

Anyway, got it published...

@remicollet
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Contributor Author

remicollet commented Dec 12, 2024

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants