This is a blog of current Qcodo and Qcodo website development activities. Official Qcodo announcements will also be posted here.
With the release of PHP 5.2.14 (as well as PHP 5.3.3), today “marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance. Security fixes for PHP 5.2 might be published on a case by cases basis. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.”
Fortunately, Qcodo has been fully compatible with PHP 5.3.x for quite some time now, while still maintaining full support for users still on 5.2.x.
Note that Qcodo has not yet begun to provide support for PHP 5.3.x-specific functionality (e.g. namespaces) in order to maintain backward compatibility with folks still running PHP 5.2.x. But with today's announcement, hopefully this will begin to start moving more and more users in the PHP community to start migrating towards 5.3.x. And so while we are still quite a ways away before we can begin implementing things like namespaces into Qcodo, at least it is something we can begin talking about and considering / planning for.
Isn't it time to drop support for php versions < 5.2 ?
Other than the Legacy QDateTime class (which we have already stated is not getting any “new” functionality), I don't think there are things that we are explicitly doing that specifically targets PHP < 5.2...
Pretty much any functionality / feature / fix in Qcodo which supports 5.2 and 5.3 will naturally benefit 5.1 and 5.0.
Furthermore, there are no language constructs that are 5.2-specific which are not in 5.1 and 5.0 that I know of.
So, unless I am mistaken (and please correct me if I'm wrong), the only < 5.2 thing is the Legacy QDateTime class -- and at least for now, I don't see a huge benefit in removing it since it doesn't really cost us anything to keep it in there.
Qcodo already is using some things that are not compatible with php versions < 5.2 .
An example of this is the function “memory_get_peak_usage” used on line 64 of codegen.cli.php, the Pdo drivers or the Soap server implementation.
I'm pretty sure that there are other incompatibilities too.
I really doubt that somebody is using a new version of qcodo with a php version of more than 4 years ago.
If we end support for php versions lower than 5.2, we could not only erase some old code (fewer bugs :) ) but also get rid of some ugly hacks like :
if (version_compare(PHP_VERSION, '5.1.0') == -1)
(QQuery.class.php line 54)
Furthermore we can take advantage of new functions, classes, etc...
Here's a list of some php 5.2 advantages:
Just my two cents...
Sorry, my browser crashed and I wrote the reply again :P
Function spl_autoload_register() is used by qcodo autoloader, this function is present only in php >= 5.1.2
I think this was introduced in 0.4.0, since that time I didn't noticed any complaints on this about qcodo not working on old php versions.
I've written to Mike Ho about qcodo php requirements and this function in an email ages ago.
Yeah, and I just wanted (for other folks) to reference Zbyszek's Wiki post which does start to discuss this as well:
I think we should stick with “PHP 5.1.2 or later” for now as the officially supported PHP versions for Qcodo, especially since spl_autoload_register is pretty central/core to the framework and it would be too much of a hack to try and do a workaround.
I've removed any of the old version_check code for PHP 5.0.x (e.g. including the references to QQuery.class.php you made above). Now, the only version_check we do is with regards to checking for 5.2.0 or later, and using QDateTime or QDateTime-Legacy based on that (in qcodo.inc.php).
Any other post-5.1.2 functionality should now be checked against function_exists() first -- so for example, any code that references memory_get_peak_usage (which requires PHP 5.2.0 or later) is only called after verifying function_exists(). Since any calls to memory_get_peak_usage in Qcodo are “nice to have” but not critical to core functionality, I think keeping the official “Minimum PHP Version” at 5.1.2 will be fine.
If you have any comments or questions about this, please don't hesitate to post!
Otherwise, all these code cleanups should be in the 0.4.17 release.