Drop PHP 5.5 in favor PHP 7.1


#1

Hello @hoackers,

Currently, Hoa still requires PHP 5.5. We didn’t drop it for PHP 5.6 exceptionnally because we didn’t have time for that… But now, I think this is time to drop 5.5 in favor… PHP 7! What do you think?

Of course, it will be considered as a BC break, and following the Rush Release rules, we will increment the x part of one, so for instance hoa/ruler 2.x will move to 3.x.

Thoughts? Do we follow the rules, or do we keep this version so far? This is an opened question. My personal opinion is to follow the existing rules and drop PHP 5.x, but I am wide opened.


Hoa Virtual Meeting
#2

5.6 is still supported in term of security (end in end of 2018) and I don’t have he impression that people have still migrate to 7.X. I know that many people plan to move to 7 during this year. So perhaps you should wait a bit and going to 5.6

so for me => 5.6


#3

I think we should drop 5.x in favor to 7 and if a bugfix must be apply we can still keep 5.x updated.


#4

Hello,

It’s really complicated, in one way PHP 7 is more and more used each day and add a lot of improvements but they still have a lot of PHP 5.6 at least. If we trust statistics from https://seld.be/notes/php-versions-stats-2016-2-edition and from https://dashboard.telemetry.atoum.org/dashboard/db/environments we still have a lot of users using 5.6.4.

I am in favor to drop PHP5.x support for PHP7 but I don’t know if this will not create too much gap for users. And PHP-5.6 it’s still in “Security fixes only” mode http://php.net/supported-versions.php

For me we should stop support PHP-5.5 but not necessarily remove the code for now. I think it’s better to wait the end of life of PHP-5.6.


#5

Pros of 7.0, and even 7.1 (I am not listing everything, just features that are interesting for us):

As you can see, several features from PHP 7.0 and 7.1 are required for our 2017 roadmap.

What I would like is: Drop 5.x, drop 7.0, go directly to 7.1. The roadmap will take time to get there, updating the code to 7.1 will take time too, I don’t want the project to be using 7.1 features and 7.1 will be outdated.

Popular libraries are stable. Most of the others are stable too. Maybe we could maintain a special branch for bug fixes, even if this is against our Rush Release policy (we could accept this as an exception if really required and blocking).

Thoughts?


#6

OK, so if we follow this idea. We will have to refactor all libraries to handle 7.1 with our Rush Release, and only if we have bugfix which required a fix with lower version of PHP we maintain it and create a tag from another branch ?


#7

Can you define refactor here please?

But yes, basically we might create another branch if a bugfix need to be backported. This would be against the Rust Release principle because it is based on Rolling Release, but… reality and pragmatism :slight_smile:.


#8

When I talk about refactor, just rewrite a part of code, if needed, to use the latest functionality provided by PHP-7.1. I see this seems correct. We need to continue to maintain the current PHP version but using the latest functionality for the roadmap looks good.


#9

If we have a BC bugfix require to bump major version we cannot keep multiple versions at same time. In this case I prefer to jump on 7.1. :thumbsup:


#10

Same for me, using the PHP 7.1 features in Hoa Roadmap will help to move the code foreward. Also keeping bugfixes on PHP5.x compatible code through a branch does not break the rules, we are keeping to follow PHP versions roadmap.

Having quality libraries like Hoa moving to support PHP7.1 can help developers and users choosing to drop PHP5.x too :thumbsup:.


#11

To be honest, I have a mitigated position…

I used to think the same… but as an editor employee, working often with French ESN (sorry, I do not have the english word for it), I have to face the reality (and this is hard: making some abrupt choices can help some good developers to move forward, but will also make some others reject our product. On the other hand, if we do not move forward, we will lost a part of what makes Hoa a so exceptional product: the will to stick to state of the art.

Regarding a compatibility branch, i Agree it does not break the rules… but do we have enough power, enough energy, enough willingness to maintain this branch in parallel of our actual work on the product? I’d rather adopt the following approach: a blog article explaining why we chose to drop PHP 5.x (and we have a lot of good reasons to do it, the first one being Hoa’s way of being a state of the art product), and the benefits we will gain from this move (new RFCs must not be the main reason exposed in the blog post, but only be additional benefits of the move). then, we can explain that, given the size of the community, we do not plan to maintain a backward compatible branch, but users that would need it can contact us, and we can decide case by case. I really think we must not take any engagement about this task.

As you can see, not only I am mitigated, but I do not really give any true answer… (only my 2 cents).


#12

To be clear, we will create a new branch to backport security patches or bug fixes only if this is necessary. This situation did not happen even once in many years, we are not taking a big risk here. Even if it would happen, I am pretty sure the roadmap will be over at the end of the year, and major projects and tools will have migrated to PHP 7 during this period. The risk is getting smaller. Finally, this exception (new branch for backports) will apply to popular libraries, like Hoa\Ruler or Hoa\Websocket, but probably not for Hoa\Acl for instance. We have to be clear. We have a rolling release process, we defined Rush Release to get version numbers only to be compatible with Composer and to manage BC breaks. Maintaining 2 release “branches” is not part of the plan, this would be a strict exception to some popular libraries to not loose a marketshare and be nice with our users.

Again, I think the risk is minimal here.

Thoughts @CircleCode?


#13

So we’re taking an engagement here. I still disagree with it, but this is only my point of view: I do not say we must not do backport of security fixes, I say we must not reject the idea of doing it if users (and here, to be honest, I think important enough users) express this need. Why doing it (maintaining a backport branch) this time, and not the next time? Why not doing it previous times? I’m afraid we will not be able to restrict it to only some libraries (how do you identify them?) and to only this migration (again, if we do it this time, we will have to do it on the next major BC break).


#14

Maybe we can approach it a little differently… For the moment Hoa haven’t used compatibility branches but I see some benefits to introduce them :

  • Accompany libraries users within their project constraint ;
  • Ensure fixes (security) to be applied to reinforce the trust in Hoa quality ;
  • Apply an expiration deadline on these branches to do not guarantee lifetime compatibility.

I know that the team is not big enough to handle new developments on these branches but it can be seen as a :

We know that you use the previous version of Hoa and we also know that you can’t upgrade as quickly as we move forward. But we don’t forget you, we’ll apply security fixes during 6 months (for example) to help you move forward with us !

What that approach we’ll define when the compatibility must end and we encourage users to upgrade. After that it they don’t want to, it’s not Hoa responsability anymore to maintain old versions of the libs.

So this approach can then be used inside Hoa for each new release…


#15

Good idea! I like the approach of a lifetime for support branch.

I would like to strike that Hoa has always been compatible with all PHP versions, but this time, we are about to introduce non-backward-compatible features (like types for instance), this is why we have this talk.

Just to clarify also the thread: We all agree to drop PHP 5.x, and to move to PHP 7.1 or 7.2 directly. The last remaining question is: Do we have support branch or not?

Again, this situation is exceptional. The idea of attaching a lifetime to support branches is an excellent one. But I would like to add another argument. Who are our users? More and more I discover we have “indirect users”. Taking the example of Wallabag. Wallabag is using RulerZ, which is using Hoa\Ruler. A lot of people are using PhpMetrics or ownCloud, which are using Hoa\Ruler. Of course, we have direct users, yes, I don’t doubt that, but as a set of libraries, I think (I am not sure hélas) we have more “indirect users” than “direct users”. In this situation, what the maintainers of these softwares do? They have a big set of dependencies to manage, they don’t drop PHP versions very easily, and most of the time, they might even ignore that we exist. Our libraries have few bugs, and the surface of our API that are in use contain no bug. In such a situation, a project maintainer will not update dependencies as is: If it works, don’t touch it. That’s a reality of our business. And thus, we can update and drop PHP versions without taking care of backward compatibility, because when these softwares will update, PHP 7 will be the norm, the standard, and the dependencies will use PHP 7 as a minimum requirements. So the situation in which we will have to create a support branch is unlikely to happen.

I am not sure if I am clear, but the probability to create a new support branch is very small. I am not closed to this idea, and I am not afraid too because if it happens, it will probably be once or twice at most, so the amount of work will not be that important.


#16

I am completely agree to introduce a lifetime for a support branch. PHP have taking one long time ago http://php.net/supported-versions.php and also have a page to talk about unsupported version http://php.net/eol.php

If we introduce lifetime it must be really explicit and clear to have the date for the end of life of support branch.


#17

Hello, I’m back on this. So for me there is several thing :

  • new feature, new libs, => at leas 7.1
  • existing libs => honestly we have seen in the past that some php version are pain in the ass to move to newer version (5.3 to upper was really painfull for many people). 5.3 and 7.0 are not comparable in terms of breaking stuff (7 is easier to migrate because of libs that have been upgraded and because less shitty stuff done by dev).

For me, as an employee that require to main stuff during long time, I need to be able to use a lib (specific lib that are quite uniq like most of the hoa libs …) without issue in terms of security. If I need new feature, new stuff I can create a fork and import for backward compatibility without upgrading a lot of stuff (and I have several libs where I do it). Other wise I’m happy when I move to new php version to simply upgrade to the new version.

So for me (as employee of company) => big yes to move forward => yes (not big, because of open source contributor, but big as employee) to have a support branch.

In hoa we are special because of the low level our libs are. For this we really need to have in mind all other opensource libs that use us as base for they development.


#18

Exactly, totally agree. But most of them are about to migrate to PHP 7, so it’s OK for me.