What version of PHP should my package support? Best php traianaing trivanrum soddisfare technologies

What version of PHP should my package support?

Everybody likes “the new hotness.” Everyone loves a new car, or a new computer, or the state-of-the-art video gaming console. It’s why people camp out for days to get their hands on a new iPhone, when they could just buy one the next week off the shelf. People love to have the hot thing, right now.

Perhaps, then, it shouldn’t be so surprising that people get tremendously excited when a new version of PHP comes out. People look forward to the new features, whether they be the trailing commas in list() syntax or counting of non-countable objects.

Everyone loves a new release of PHP.

A new version of PHP can pose challenges to open source package maintainers. There are questions, like what is the minimum version we will support and how soon can we take advantage of the new features we’ve been waiting on?

I want to offer up some thoughts, both as a package maintainer and a user of many open source packages.

To me, an open source package should provide support for the lowest supported version of PHP that is available. Right now that means PHP 5.6; PHP 5.6 is supported through December of 2018.

Why should package maintainers support the lowest supported version of PHP? The answer is that there are companies and organizations that depend on your package who are unable to upgrade for a variety of reasons. Most are in the process of upgrading, but they need more time. Packages that quickly bump the minimum version requirements from an older version to a newer version of PHP leave behind a huge segment of the community that depends upon that package.

This isn’t to say that developers shouldn’t take an opportunity to use new features. Creating a new version of the package (major version bump) with new features dependent on new language features is perfectly acceptable. But it’s important to continue supporting older package versions for a reasonable length of time. Sebastian Bergmann does just this with PHPUnit. PHPUnit 5 (the only supported version of PHPUnit with PHP 5.6 support) will have support until February, 2018; after that, PHPUnit 6 will be the only supported version and targets PHP 7.

One argument I often hear in favor of bumping the minimum version is that we want to encourage users to upgrade. This is certainly true: we want to encourage users to use the most modern version of PHP available. Where we see a problem is when we force them into a no-win situation: upgrade to a version of PHP you can’t currently support (usually for business reasons) or lose any and all support (including security fixes) for your open source packages.

So what is a package maintainer to do?

First, I believe package maintainers should feel 100% comfortable making the newest version of PHP a minimum requirement – in major version bumps of the package. For example, if v1.0 supported PHP 5.6, then v2.0 could support PHP 7.2 (the most current version of PHP as of this writing), and implement new features that depend on PHP 7.2.

Second, in my opinion maintainers should make every effort to support the lowest currently supported version of PHP, through providing support for older packages. This support need not be comprehensive; it can simply be security-only fixes. The key here is that package maintainers not abandon users of the package who are using it on older (but still supported versions) of PHP. For example, if v1.17 is the last version providing support for PHP 5.6, then I would continue supporting v1.17 until PHP 5.6’s end of life.

Third, once a version of PHP goes out of support, package maintainers should abandon support for any version of their package that targets that minimum version, and should rev to at least the lowest supported version of PHP going forward. For example, no package maintainer should provide active support for a PHP 5.5 package; that package should target PHP 5.6 as a minimum. We must encourage users to switch to supported versions of PHP and get away from unsupported versions of the language.

Supporting old versions of a language isn’t fun and isn’t glamorous. But it’s important. It’s important because there’a segment of the population who can’t upgrade yet. It’s important to make components accessible to a larger, broader audience who is struggling to find best practices and use modern packages. And it’s important for those users who are tied to a legacy version, and are struggling to get upgraded. But it’s the right thing to do for the community.