Support for PHP 7.4 with endroid/qr-code v4

[philippeaellig]

hi there why php 7.4 support is dropped? just because of this one test? because everyone how use magento version < 2.4.4 will run magento with php < 8. Install a version 3.2 of this module is not possible, because magento use endroid/qr-code 4, bust 3.2 use version 3.9. i'm not able to install this module in magento < 2.4.4...

• magento/product-community-edition 2.3.7 requires msp/twofactorauth 3.1.3 -> satisfiable by msp/twofactorauth[3.1.3].
  • sprain/swiss-qr-bill v3.3 requires php ^8.0.0|^8.1.0 -> your php version (7.4.27) does not satisfy that requirement.
  • Root composer.json requires magento/product-community-edition 2.3.7 -> satisfiable by magento/product-community-edition[2.3.7].
  • msp/twofactorauth 3.1.3 requires endroid/qr-code ^4.0 -> satisfiable by endroid/qr-code[4.0.0, ..., 4.x-dev (alias of dev-master)].
  • endroid/qr-code 4.x-dev is an alias of endroid/qr-code dev-master and thus requires it to be installed too.
  • You can only install one version of a package, so only one of these can be installed: endroid/qr-code[dev-master, 3.9.7, 3.x-dev, 4.0.0, ..., 4.4.7].
  • sprain/swiss-qr-bill v3.2 requires endroid/qr-code ^3.9.7 -> satisfiable by endroid/qr-code[3.9.7, 3.x-dev].
  • Root composer.json requires sprain/swiss-qr-bill ^3.2 -> satisfiable by sprain/swiss-qr-bill[v3.2, v3.3].

[sprain]

See https://github.com/sprain/php-swiss-qr-bill/issues/160#issuecomment-997706493

But yes, there is no version of this library which supports PHP 7.4 and endroid/qr-code v4.

PRs are welcome, if there is a need for this.

[philippeaellig]

i created a php 7.4 compatible version for my use case. https://github.com/WeLoveYouCH/php-swiss-qr-bill

[geekdevs]

seriously though?! Dropping support of php 7.4 - the most used php version currently is really weird.

[sprain]

@geekdevs v3.2 works perfectly fine with PHP 7.4 and supports the full feature range.

You're all welcome to contribute and provide compatibility. The beauty of open source is that all can benefit from each other.

[geekdevs]

Don't get me wrong, I value and appreciate all the work you're doing on this bundle and do not mean to offend you in any way.

I support moving forward to newer versions of php, but dropping support of most popular php version looks quite extreme to me. Supporting two isolated versions of a bundle is a pain, unnecessary pain.

On top of that I was actually forced to make a fork because some classes were mark as "final", quite a luxury for open source project meant to be used by wide audience. I can of course work around these limitations and adjust code in any way possible. But I think it's also a responsibility of a repository owner to try making things easier for the users, not harder.

These are just some of my observations. Either way thank you for providing such a useful library and saving us lots of time.

[philippeaellig]

i understand the beauty in the code, on dropping the support for php 7.4 and use new features. but there are software packages like magento that can't use this package. because exactly version 3.2 has to be used and in the version 3.2, this package require endroid/qr-code in an older version than magento. and that doesn't work, because the version of this package is too old for magento. you have to be very lucky that every package fits exactly in the version, if all versions are locked and php is limited to just one minor version. if php support would be a bit wider, the change would be there that we can use this package in our projects like a magento store. i don't speak about php 5.6 or 7.1. i speak about php 7.4... and yes, everyone can create a fork. i created a frok too. but i see a problem in all these unmaintained forks.

[sprain]

I do understand all your points and I will happily accept a pr which provides support for v4 of endroid/qr-code based on v3.2 of this library.

[sprain]

On top of that I was actually forced to make a fork because some classes were mark as "final".

Which class did you want to extend and why?

Generally, I prefer and promote the use of composition over inheritance.

[geekdevs]

@sprain I already wrote about this here https://github.com/sprain/php-swiss-qr-bill/issues/29#issuecomment-943405048 I had a case where customerIdentificationNumber needed to be longer than 11 characters. Sure, I would prefer composition also if it was possible if it had small, replaceable parts which I could easily switch. Here I don't see much options other than copying the whole QrPaymentReferenceGenerator class though.

[sprain]

@geekdevs Thanks! The real solution in #29 would be to get a better understanding of what customer ids are possible and then adjust the library accordingly. So making the class final actually made us aware of a potential bug, which is a good thing.

[zaietsv]

I noted that PHP 7.4 support was dropped between releases 3.2 and 3.3. Apparently it is a good practice to make MAJOR versions update while making backward incompatible changes. I think it is a good idea to update PHP major version dependency at a major release 4.0 or so on.

[sprain]

I am closing this as PHP 7.4 will be end of life in a week and PHP 8.x is now consistently above 50% in installs.

[sprain]

@zaietsv I only saw your comment now. Dropping a php version is not a bc break. The Doctrine project explains it nicely:

One question we frequently hear is, "isn't dropping support for a PHP version a BC break"? In a nutshell, no. A BC break happens when there is an incompatible change that your package manager can't handle. For example, changing a method signature in a minor version is a no-go, since the composer version constraints mentioned above assume any minor upgrade can safely be used. However, when we drop support for an older version of PHP, composer will not consider the new version if the PHP version requirement is no longer fulfilled. Thus, you won't end up with a fatal error due to a wrong method signature, you just won't get the new version.