Skip to content
This repository

Minimal PHP version requirement #35

Closed
qiangxue opened this Issue · 60 comments

23 participants

Qiang Xue bwoester Paul Klimov Alexander Makarov Carsten Brandt kavitama jabbon Ray matthewyang Alexander Bolshakov Evgeniy Kuzminov Rami Veaceslav Medvedev psihius phreakbg Panagiotis Moustafellos Vasilis Lourdas Charles Pick Timethor Vladimír Kriška Luciano Baraglia Tobias Munk
Qiang Xue
Owner

This ticket collects the minimal PHP version requirements from various classes. We will determine the final minimal version requirement when we finish the core framework classes.

bwoester

Just found this project: PHP_CompatInfo
Maybe it can be included in the Travis configuration. Both to help finding minimal PHP version requirements and later to ensure new commits don't introduce higher requirements.

Paul Klimov
Collaborator

I can not tell for everyone, but I usually deal with Linux CentOS as a basis of web server. Since CentOS is a free version of RedHat, it is common choice for the server systems, which do not require any visual interface.
Currently, the latest available PHP version at CentOS is 5.3.3, which is already too low for Yii2. However you can at CentOS you can use ‘Remi’ respository, which provides the PHP version 5.4.20.

There are several major advantages, which Yii can benefit from using PHP 5.4:
– Usage of traits can increase code reusage and flexibility
– Array short syntax ([‘a’=>’b’]) can “purify” the code appearance

In our pursuit for the better functionality we have already raised the requirements up to 5.3.8, why stop there?
The Yii1 was released and supported to be compatible with 5.1, which becomes deprecated very soon after release, while support for the features from 5.3 (such as namespaces) created a issues, which have been resolved only lately.
If we are going to step into PHP 5.4, we should do this as early as possible to develop framework, which matches its features and needs.

We have already found that at least Ubuntu and CentOS do not support PHP 5.3.8 natively, I would not be surprised if many other Linux distributives will have same problem. If we have already overcome the common restrictions, why we can not overcome them further for the “better future”?

Paul Klimov
Collaborator

At these “stats” it is hard to tell which exact “5.3” version is used. I assume in this statistic “5.3” means “5.3.3”. I doubt it matches “5.3.8”.

Paul Klimov
Collaborator

As I said before, I am afraid we have already overstep the most spread PHP version by requirement of “5.3.8”

Paul Klimov
Collaborator

OK, let’s do some precise calculations, just in case.
Version 5.* is used in 97.3%, so assume it covers 100% just for simplicity.
5.3 is used in 52.0%
5.4 – 8.1%
5.5 – 0.5%
So 5.4 + 5.5 = 8.1% + 0.5% = 8.6%
Now, not every 5.3 version matches Yii – only 72.1% of 5.3.* usage matches 5.3.7 or higher.
52.0 * 72.1 / 100 = 37.49 % – usages version 5.3, which matches Yii.

Summary:
1) For requirements 5.3.7 usage percentage equals to 46.09%
2) For requirements 5.4.0 usage percentage equals to 8.6% (18.65% of the 1st one)

Alexander Makarov
Collaborator

Yeah. So while 5.3.7 looks like safer approach compared to 5.4. Featurewise there were no things we can't do with 5.3 till @cebe refactored AR to use traits. So far that's the only valid usage. Short array syntax is just a bonus, not a tech stuff.

Qiang Xue
Owner

Can we get the list of major shared hosting providers and see what PHP versions they support by default?

For Yii applications developed to run on dedicated servers, PHP version is not a problem.

The problem mainly exists for applications running on shared hosting environments, especially if Yii is used to developed a generic application such as forum, CMS, whose minimum requirement should be as low as possible.

Alexander Makarov
Collaborator

@qiangxue which are major? And where? I think I can get stats for Russia.

Carsten Brandt
Collaborator

added the major german hosters.

kavitama

On one side, while a good number of hoster have included 5.4, a good part is still using 5.3 as a base and that would mean more garanties of "YII spreading"

On the other side I would go with 5.4 to enforce a more robust PHP base that could simplify some YII choices.

Just my 2 cents thought:

jabbon

Vote for PHP 5.4

Qiang Xue
Owner

If we choose to go with 5.4.x, what x should it be?

kavitama

5.4.0

Carsten Brandt
Collaborator

agree with 5.4.0 as long as we see there are bugs that we need to have fixed to make yii work properly.
Scrolled through the CHANGELOG and did not see anything that might be relevant.

I vote for PHP 5.4 too. Regarding minor version the answer would be ".0 or whichever other minor version is needed to do what we want".

The thing is that we can look at usage statistics as much as we want, but at the end of the day the choice we make now is one that will stick for the entire lifetime of Yii2 (or at least Yii 2.0), and that's probably going to outlast peoples' old PHP environments.

Ray

vote for 5.4

matthewyang

Just collected a list of php version required by other framework/applications.
Symfony2 - 5.3.3
Slim - 5.3.0
Laravel - 5.3.7
CodeIgniter - 5.2.4
CakePHP - 5.2.8

Wordpress - 5.2.4
Drupal 6: PHP 4.4.0 or higher (5.2 recommended).
Drupal 7: PHP 5.2.5 or higher (5.3 recommended).
Drupal 8: PHP 5.3.10 or higher.

Joomla: http://www.joomla.org/technical-requirements.html, 5.3.1+

Choose 5.4 looks a bit aggressive.

Alexander Bolshakov

Choosing 5.4 along with using it's features doesn't seems aggressive, but progressive

Alexander Bolshakov

Probably there is need in public voting on related websites like yiiframework.com

Evgeniy Kuzminov

As I understand this question was rised a lot of times and the most correct anwer was - if features from php 5.4+ will be used in framework and it will bring significant improvement, then it is a reason to raise requirements.
But in this discussion everyone just posting their votes for 5.4 and noone brings any arguments except @klimov-paul :)
It is a bit strange that you are trying to make decision based on statistics of hosing providers and even more strange to compare Yii's requirements with other framework requirements.
As I could get - the only real usage of 5.4 features was made by @cebe in branch ActiveQuery with traits, so if it is really usefull then it is an argument.
All other "new features" of 5.4 are mostly syntax sugar - shot arrays, array dereferencing, Class::{expr}() etc. and at first look framework could leave without it.
And of course we shoukl keep in mind real most common usage flows of a Yii framework - I don't really know how to get such kind of statistics, but what part of projects made on Yii is hosted on shared hosting and what part on VPS etc. ?
(As for me it is a hard question as in my company we are making quite big projects and using custom OS installaton with all latest soft, so using PHP 5.5 right now, so I wonder - maybe most of other users also has an ability to install required PHP version ?
As serious projects are not hosted on shared hosts, and small sites are not beng written on frameworks, mostly ready-made CMS are used, and only big and pet-projects are left and all of them are mostly hosted on VPS, where you can setup whatever you need).
Maybe I am wrong in statements above, only my imho.
Default version of PHP in repos of most distros are not so big issues as for me, there are a lot of 3rd party repost with latest PHP versions.

Rami

Seems like the majority of framework/applications require php 5.2.x BUT it's only because of the need to fit for majority. Many of those applications have open tickets examining it's minimum requirements.

PHP 5.2 is no longer supported, so the question is whether to use 5.3 or 5.4 or 5.5? Everyone will agree that PHP 5.5 is out of the question.

Now remember that each php version is supported for 3 years and version 5.3 is reaching it's end of life (http://php.net/archive/2013.php#id2013-07-11-1), it will be supported for 9 more months - until July 2014. Do you want to start this discussion again in a year from now?

In my opinion, php 5.4 is more appropriate. It's a bold move, i agree. But i think in a year from now you will see that it was the right move.

We all hate code redundancy :)

Veaceslav Medvedev

Yii out when 5.3 was not. The choice was obvious. But in two years, would be 5.3, and it seemed that the Yii is outdated.
Now php 5.4 came out a year ago, to the release of at least two Yii 2. I fear that the Yii 2 out, version 5.3 will declared 5.3 EOL.
And again, many who will choose a framework, Yii will pass as obsolete.

psihius

First of all, PHP 5.3 is in the End Of Life (security fixes only) since July 2013, in 9 months (July 2014) any support for 5.3 is gone for good.

Second is partly growing from the first: Yii 2 is not compatible with Yii 1 - if you migrate, you have to rewrite most of your code anyway. Yii 2 is in Public Preview - not even in beta, so the release is far away at this point - I don't think it will reach stable by the end of EOL for 5.3, so I don't see the point of releasing a framework with the version requirement lower than the lowest maintained version of the language available at the moment (at that point that will be 5.4). And 5.3 has some bugs - as an example, PDO bug when float get's truncated to int (WTF?!!!) - that are fixed only by unofficial packages released by community through PPA and others (official packages never got updated to versions that fix it). And newer distro releases for the most part have 5.4 (as I see it in the google docs, and waiting for a few like Debian stable is pointless - they always are too far behind, that's their niche).

Third - 5.4 has only traits as big functionality update, but it has massive improvements in memory usage and speed that make a big difference.

My point is that this is a new framework release, aimed at new future projects. There is no backwards compatibility to think of, by the release time probably 5.6 will be out and 5.4 will enter EOL security-fix only mode (the 5.6 release process was kicked into gear just yesterday on the php-internals and by their own release process, they 3 active branches tops - by next spring that would be 5.4 in EOL, 5.5 in maintenance and 5.6 as current stable). That is why 5.4 as minimal version required is logical. Think to the future.

Evgeniy Kuzminov

@ramiy , @psihius , @slavcodev
Don't forget that we are talking about MINIMUM REQUIRED version of PHP, but not about RECOMMENDED or "the best one". Framework can't require 5.4 just because 5.4 "has massive improvements in memory usage and speed that make a big difference." - that doen't make any difference to a framework by itself.

If 5.3 or 5.4 in (or will become soon) EOF state it does not mean anything for a framework if it still state these versions as a minimum requirement, as soon as it works fine with nevest PHP versions.

Paul Klimov
Collaborator

I have already posted the major benefits from usage of 5.4. Now I will try to explain why they are major.

1) Using of traits
Back when I was studying at the University “multiple class inheritance” (supported only by C++ at that time) was considered as “bad practice, which should be avoided”. Later the attitude for this feature has changed, due to such programming languages as Ruby and Python. They converted original paradigm of C++ into ‘mixings’, which in PHP are called ‘traits’. Mixing is a simple analog of the class, which bear some basic standalone functionality, which can be shared among different other classed from different hierarchies.
Lack of this feature in Yii1 introduced ‘behavior’ feature.
Still ‘traits’ can’t replace the ‘behaviors’ entirely. In some cases functionality organized as behavior better be converted into a trait, but in some cases it is too complicated or impossible. While Yii introduce the ability of “intersection” of the classes it should consider the “trait” mechanism usage.
If we accept traits, we should

  • reconsider ‘behavior’ mechanism
  • reconsider framework classes organization and class hierarchy
  • think if Yii should provide some functionality as a trait (for example quick cache interface for the classes)

2) Array short syntax
This may looks just like not significant feature, which only save you some redundant symbols. But it can be more into it.
As you may notice Yii widely using ‘DSL’ (domain specific language) inside the code. Just remember how you declare the validation rules in the model class, how you declare the ‘pretty’ URL rules, and, of course, do not forget newest addition of syntax $object->{on Event} $object->{as Behavior}.
Short array syntax is tool, which can be used to improve the existing DSLs and create new ones.

Imaging of future issues
When PHP will finally overcome to 5.4, we will have to deal up with issues like

  • “Please extract this functionality into a trait, I have to duplicate too much code to create an extension”
  • “magick ‘__call()’ is too slow, why we do not use trait instead?”
  • “Basic application config is messing, why you do not use short array syntax ([])?”
  • and so on
Alexander Makarov
Collaborator

Technically we're fine with 5.3. Using 5.4 we can add some features but these are not really that great. Choosing 5.4 is logical from marketing point of view though... initially Yii will lose user base because of shared hosting but then it will gain user base back because it's not using 5.3 that will not be supported anymore.

Alexander Makarov
Collaborator

So even if we're going to stick with 5.3 it is probably worth writing something like the following in readmes:

Although we officially support 5.4 as minumum required version, the code is being developed to work on PHP 5.3.7 and higher.
Veaceslav Medvedev

@samdark If the code will be developed to work on 5.3.7 this means that the behaviors the same. But the magic logic which looking for methods and properties for all behaviors, too hard. Trait is the main benefit to use a 5.4.

phreakbg

I think that Yii 2 is still in development, and by the time it goes stable 5.4 will be the major version that is most commonly used. I vote for 5.4.

Veaceslav Medvedev

Yes now 5.4 not using on most shared hostings, but Yii released in 2014, and situation will be change.

Alexander Makarov
Collaborator

Nah. Check stats again on 5.2 support. It's still 30%+ while EOL was reached in 2011.

psihius

As I proposed to @samdark in the Skype and he wrote here above, it can be a case of officially having the minimum version set to 5.4, but unofficially supporting 5.3.7 or whatever.
I think that having an official minimal version of 5.4 does not restrict the ability to bump versions in 5.4 tree (for example, if a critical bug or security vulnerability, or a segfault is discovered), just like with 5.3 Yii 2 does not work with versions lower that 5.3.7 because of bugs, functionality or whatever. And you can drop the unofficial support for 5.3 if it get's in a way (and I belive that will happen sooner or later). This will provide a grace period for those, who have to stick with 5.3 for whatever reason, but they will know that they have to move to 5.4.
Also puts some pressure on the hosting providers, because clients will ask for 5.4

Qiang Xue
Owner

Although we officially support 5.4 as minumum required version, the code is being developed to work on PHP 5.3.7 and higher.

How will this work if we use traits in core code such as ActiveRecord?

Carsten Brandt
Collaborator

If we officially require 5.4 we also want to be a 5.4 framework that really uses the benefits that come with this version. I can't see why we should silently keep BC to 5.3.x while we are not telling it. This generates confusion about the version requirement for users so they can not be sure whether they are save with 5.3 or not. There should be one minimum requirement and that should be based on real technical requirement because of technology actually used.

Alexander Makarov
Collaborator

@qiangxue that's in case we do not :)

@cebe overall I agree. It seems we need 5.4 for mainly marketing reasons but not using it while we're telling we require it is kinda silly.

Panagiotis Moustafellos

Adding to the points made by @klimov-paul; 5.4 also enables referencing the object instance from Closures which is a great feature.
IMHO, its a step forward and embraces the somewhat delayed maturing of PHP to use 5.4 as a base and completely abandon 5.3 which has reached EOL.

@samdark makes a valid point as well, it does make a nice marketing catch as well, hadn't crossed my mind. It is not a reason alone of course, but it is a side-benefit.

@cebe has already made some commits on redis branch (I think?) and has reduced the LoC significantly. This is great.

So, 5.4 (with a prompt to use latest stable release number) has my vote.

kavitama

EOL is important not only for marketing stuff but also to decide which functionalities can be used in YII2.
Supporting 5.4 and unofficially supporting 5.3.x is nonsense.
Using 5.4 as a base means change parts of YII to take advantages of that platform: i dont think the marketing should drive the decision.
And more...
I dont think the target for YII applications are only shared hosts programmers: in any case this will allow users to choose new hoster with better support

As usual, my 2 cents opinion

Vasilis Lourdas

In my opinion, Yii 2 is far away for being in beta stage and it will take longer for the stable version release than the EOL date of PHP 5.3, so the logical decision is to go with PHP 5.4. Main reasons to go for 5.4 for me are:

  • Syntactic sugar/features, like traits, array dereferencing, etc.
  • Greatly reduced memory usage.
  • Marketing stuff, "hey man, this must be great, it requires PHP 5.4!", so it gains popularity.

As @iJackUA said, one that is serious about using Yii 2 in a web application, they will go with at least a vps, where they have control of what they can install. Debian 6 was frozen with PHP 5.3.3, but I used the dotdeb repo to update to the latest 5.3.27 to resolve some issues that I faced with the earlier versions. Debian 7 is with 5.4.4. Upgrading to 5.4 will be a great benefit for all these shared hosting providers, because of the reduced memory footprint of PHP 5.4.

If Yii 2 was a couple of months away from release, then maybe I would say go for 5.3, but as @samdark said, this is just a minimum requirement, not the recommended one.

matthewyang

I agree if base on 5.4 could make a better Yii2, not just for marketing reason.Actually if we can keep the lower version requirement and get much better Yii2, market will more like to see that.Because it means a much better framework can reach more potential users.

What makes Yii2 a better framework? Not the new syntax we can take advantage of from new PHP version.
But if the new syntax can improve this framework a lot and also the PHP version that support this syntax are available wide enough, then we should use it.

So there are 2 things we need to weight here:
1.to make a better framework, that's our only goal to develop Yii2
2.to reach as many user as we can(PHP version availability)

Charles Pick

when 2.0 was first announced, targeting 5.3.x seemed like a good idea, but that was quite some time ago and the world has moved on. 5.4 is just about everywhere and it's not in our interests to support the few remaining webhosts who don't support it - serious users will not be using shared hosting, and casual users are free to switch to shared hosts that do support 5.4 - essentially this is a problem the market will fix.

Switching to 5.4 is actually quite an exciting prospect, because, potentially, almost all methods and properties could live in traits. For instance, you could have a ValidatableTrait, a ModelTrait, EmitterTrait etc, which open up all sorts of interesting ideas - a class representing a database table could use ModelTrait, which would make it possible to write actions and views that display and manipulate the database structure directly, just as if it was any other kind of model. Taking this approach to its logical extreme means there'd be very few or no abstract classes, and instead classes would be composed of one or more interfaces and traits. Composition over inheritance.

Evgeniy Kuzminov

@phpnode it looks like such rethinking could delay Yii2 for another 6-10 months :)

Charles Pick

@iJackUA right, it's unfortunate that this discussion is happening now and not 6 months ago, but this is still alpha, and I actually don't think this would be impossible to do quickly, functionally it would be the same as present - it's really just a very large refactor

Timethor

This really isn't a question of what is appropriate right now. Rather, it is a question of what Yii2 should be developed for right now so that, upon release of a stable version, it will be at the forefront of the market, not just in PHP version but in quality of framework.

Let's be realistic. Just looking at the issues here in git, alpha is a month behind with 4 issues left to close, beta is 10 days past with zero closed issues (granted a lot of them are in dev or under discussion)... But a stable release is still about 3-4 months away, minimum. Now, lets take the approach of some of the folks above did in terms of PHP EOL... 4 months from now 5.3 will be 5 months from EOL? There needs to be a notion of forethought here and not, "OK, what seems appropriate for right now?".

Developing with 5.4 NOW will lead to a perfect spot in the market when a stable release comes out. To those that have said, "What's the use in declaring a version that we aren't using features from?", again, we have to have a focus on what is to come. Minimum, there are 3-4 more pre-release development months to utilize those features that 5.4 offers. Then, you have to think, after Yii2 has a stable release there is still going to be active development. Things just don't stop and transition to bug fixes, at least not entirely. Remember, there was 2.5 years b/t Yii1.1 and the current Yii1.1.14 release.

Sticking Yii2 with 5.3 is not a viable move in the long run. That leaves 5.4 since 5.5 will still be too far ahead of the game upon release of a stable version. Really the only matter after that is one of deciding between 5.4.0 or 5.4.x. Of course, we still need to be thinking about what will be the norm 5-6 months from now. I think it's somewhat safe to say we will ,at least, start to see the 20-40% usage each for 5.2 and 5.3 that we see right now will change to being 5.3 and 5.4 in that 6 month time frame. Furthermore, When 5.3 was widely adopted, it wasnt at the 5.3.0 level, it was a few sub-versions after that.

I think the solution is to decide on 5.4 now and pick a 5.4.x closer to release. This gives the capability for traits, et al, for the rest of the duration till release while allowing flexibility for what is to come when 5.4 is actively adopted.

Vladimír Kriška

PHP 5.4 :+1:

  • better performance
  • traits
  • array short syntax
  • on Debian 7 is PHP 5.4

And @websupport-sk (biggest webhosting company in Slovakia), supports 5.4. :)

Qiang Xue
Owner

Based on this discussion and our internal discussion, we will go for 5.4.

For 2.0 release, I don't think we should introduce significant architectural change because of traits because it would otherwise significantly delay 2.0 release (again).

The main work to do for 2.0 is using short array syntax and short echo syntax. Of course we also need to review the AR refactoring proposed by cebe.

Simone sensorario referenced this issue from a commit in sensorario/yii2
Simone sensorario Merge branch 'master' of github.com:yiisoft/yii2
* 'master' of github.com:yiisoft/yii2: (1471 commits)
  Remove PHP 5.3 Travis build rule. Related to #35.
  Remove use ($this). Related to 9e1b498.
  PHP 5.4 supports $this with closures.
  Fixes #999.
  Just simple support PostgreSQL in QueryBuilder
  debug panel : changed .json to .php
  debug panel : change json_encode/decode to serialise/unserialise to prevent non-UTF characters error
  typo fix
  Fixes #930: Added i18n docs about configuring message source
  commented private property
  Fixed typos
  fixes #995
  More on GII buttons
  Fixed option merging in Console::prompt()
  changed default button style
  typo fix.
  Refactored getModule and hasModule.
  Added intl check to tests, better error reporting, credited Aura.Intl for the most complex test pattern
  Better MessageFormatter tests
  GII sub-modules support - see #871
  ...
ea52487
Qiang Xue
Owner

What coding style should we use for the short echo tag? How about this? <?= $this->title ?> That is, the expression has a space before and after it, and there is no semicolon at the end (since this is not a statement).

Alexander Makarov
Collaborator

@qiangxue I've already replaced everything to use <?=. Semicolons are still there but I'm for removing these as well sice it looks cleaner. Not sure about spaces though.

If short echo tag notitation is to be used, I think it looks good like @qiangxue wrote it. No need to remove spaces, it would just make it less readable without any practical gain. It would also look weird when one enters an expression that contains a space.

Alexander Makarov
Collaborator

Adjusted short syntax c2dabfa

Luciano Baraglia

Should short echo syntax relpace all echoes in views or there are some cases it shouldn't?
I mean, for example multiple lines (as in widgets rendering).
See for example: https://github.com/yiisoft/yii2/blob/c2dabfa78e5dfc8863b7137173e71afe9393187a/framework/yii/gii/generators/crud/templates/views/create.php#L29

I could help adjusing those... (I am always doing doing the hard work :smile: )

Alexander Makarov
Collaborator

It should except when there are multiple lines. Would be great if you'll help with these and test it.

Tobias Munk

We've used Short-Echo Syntax extensively in gtc (for Yii 1.1). I am adding a link to give you some impressions. It improves readability a lot. https://github.com/schmunk42/gii-template-collection/blob/master/fullCrud/templates/slim/_form.php

Carsten Brandt
Collaborator

@schmunk42 we already applied short echo syntax all over the framework code :)

Tobias Munk

I added it, because of samdark's comment:

It should except when there are multiple lines.

I think even for multiple lines, especially for gii, short tags are great ;)

Qiang Xue
Owner

closed as we have chosen to use 5.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.