PHP 5 Support Timeline

With the new year starting the PHP project is being asked to decide about the PHP 5 support timeline.

While Aligning PHP 5.6 support timeline with the release date of PHP 7.0 seems like common sense to keep the support schedule continuous, there’s a big question whether to extend it further to an additional one year of security support till the end of 2018. This would make PHP 5.6, the last of the PHP 5 branch, to have 2 years of security support and de facto getting the same life span as PHP 7.0 would (ending support of both in Dec 2018).

But beside of support issues, this also affects adoption rate of PHP 7.0, serving as a catalyst due to end of support for the PHP 5 branch. My concerns are that with the additional security support the project would need to deal with the many branches (5.6, 7.0, 7.1, 7.2 and then to be 7.3 branch).

I think we should limit what we guarantee (meaning keeping only one year of security support till end of 2017), and encourage project members and the eco-system (e.g. Linux distributions) to maintain further security based on best effort.

This is already the case for out of official support releases like the 5.3 and 5.4 branches (examples for backports done by Debian: 5.3 and 5.4). And of course, we also have companies that make their money out of long term support (e.g. RedHat).

On the other hand, we should help the eco system in doing such extended support, and hosting backported fixes in the project’s git repo instead of having each Linux disto do the same patch work on its own.

1 Comment

Filed under PHP

One response to “PHP 5 Support Timeline

  1. This is a very important topic that you are raising, Lior.

    Would I be wrong to assume, that the end date for security fixes is the most relevant for most PHP users?

    In that case, the effective date is basically the same, and you are right to assume that this will have an effect on the adoption of of the 7.0 branch.

    I would suggest that you give one more additional time line, and that is for any 7.x version with backwards compatibility. It might very well be that users who had any experience with pains of moving from 5.2 to 5.3, and from that to 5.6, would be hesitant to move to a completely new branch without a good enough reason.

    Giving some assurances about long term security updates, would be another consideration in favor of moving forward.

    It is much easier for an IT specialist to go to hist boss and say “we need to move now to a newer version, so that we will not get stuck without security updates“, than to just say “let’s do it because it has better options for our developers“.

    And why am I veering so much towards shoving 5.6 out of the picture? Because it might prove itself as too much of an effort to maintain the security for both 5.x and 7.0 branches, when the use of the language is ever growing and so is the rate of attacks and people that are trying to find holes in it.

    It is good to see that this is a topic thatThis is a very important topic that you are raising, Lior.

    Would I be wrong to assume, that the end date for security fixes is the most relevant for most PHP users?

    In that case, the effective date is basically the same, and you are right to assume that this will have an effect on the adoption of of the 7.0 branch.

    I would suggest that you give one more additional time line, and that is for any 7.x version with backwards compatibility. It might very well be that users who had any experience with pains of moving from 5.2 to 5.3, and from that to 5.6, would be hesitant to move to a completely new branch without a good enough reason.

    Giving some assurances about long term security updates, would be another consideration in favor of moving forward.

    It is much easier for an IT specialist to go to hist boss and say “we need to move now to a newer version, so that we will not get stuck without security updates“, than to just say “let’s do it because it has better options for our developers“.

    And why am I veering so much towards shoving 5.6 out of the picture? Because it might prove itself as too much of an effort to maintain the security for both 5.x and 7.0 branches, when the use of the language is ever growing and so is the rate of attacks and people that are trying to find holes in it.

    It is good to see that this is a topic that is on your mind, as it is on your users mind as well, to be sure.

    All the best!
    Dotan

Leave a comment