Entries tagged as php 5
Related tagsdevelopment Bryan Cantrill coding debugging DTrace entertainment fun google gsoc gsoc09 improvements MacOS microsoft ms paint mysql mysqlnd namespaces opensource packages paint php php 5.4 php 6 php releases php testing php.next php53 processes solaris sun microsystems testing unicode video youtube .net acquisation ajax anniversary apc api design array assembler barcamp bazaar bc beer garden berkeley db berlin best practice birthday boredom c# charsets christmas closures comments commits computer science 101 conferences cvs data center database db delphi dsp dtrace easter ego encoding english events exception file upload froscon froscon08 froscon10 mysqli php oo php qa php.iterator japanese php svn rumors svn goto gsoc2008 ipc ipc08 karl valentin magic_quotes magic_quotes_gpc php testfest phpqa phpt planet php project managment qa releases testfest travel ulf command line json oop pdo php extensions php interactive php session php shell sqlite sqlite3 type hints codinge fileinfo ipc10 mysql proxy mysqlnd plugins party php conferences php security php54 php55 phpbarcelona phpmysqlproxy
A few moments ago I pushed the buttons and PHP 5.3.29 came out. As this is the final release for 5.3 it is a good time to look back. PHP 5.3's history starts somewhere in 2005. We knew what a pressure point of PHP was - a language made for solving The Web Problem needs a good Unicode story. So some developers went deep into that complex area and created a prototype version of PHP with Unicode support from deep within the engine. As this was a big and pressing issue and the need was obvious and the solution looked promising it was quickly areed on making that the base for a future PHP 6. And then time passed, initial enthusiasm passed and the sheer amount of work became obvious. Two years in we noticed that the ongoing PHP 6 work blocked other work - new features couldn't be added to 5.2, the current version at that time, and adding them to (at that time) CVS's HEAD.
For solving the blocking issue we decided to create an intermediate release, pacing in all the things piled up, so on 2007-09-26 we branched off a CVS branch PHP_5_3.
Branching of PHP 5.3 set lots of enthusiasm free, and people started creating features and going into heated debates about the direction we should take so I was happy when Lukas volunteered to assist in the release management as Co-RM, playing a big role in making PHP 5.3, one of the most feature rich PHP releases, a huge success which was declared stable two years after branching of on June 30th 2009!
In those two years of development, from branching of till releasing 5.3.0 stable, we saw 5,338 commits by 83 committers (also committing work by other contributors without direct commit access) seeing 10,125 files being changed, with 1,089,600 insertions and 270,921 deletions (including tests and and generated files like parsers etc.) PHP 5.3 introduced many things many PHP developers see as normal and can hardly remember not using - things like namespaces or anonymous functions. It also introduced goto, late static binding, nowdoc, ?:, exception linking fileinfo, intl, mysqlnd, ... while also being a massive boost in performance. A massive release.
While trying to release 5.3.0 we noticed issues in our process. Notable things were that we, for a long time, didn't have a fixed cut of date and couldn't offer a promise when the next release will come. As a consequence people tried hard to push features in, as they feared having to wait a few years for the net release. In consequence a stricter release process with yearly releases etc. was created. Which lead to PHP 5.4 and 5.5 being almost on time and the upcoming PHP 5.6 being well on track.
Now development of 5.3 didn't stop with 5.3.0 but saw 29 bugfix releases with 7,554 commits from 152 comitters (due to the move to git in between a single committer might be counted multiple times, on the other hand more "external" contributor's names are being kept) and seeing 4,862 files being changed, 376,187 insertions and 207314 deletions.
On the personal side being the release master of PHP 5.3 gave me the opportunity to travel between Moscow and California and teaching different audiences in multiple languages about the great work, which was done mostly by others. (Check the ChangeLog to see whom to thank for your favorite feature!)
But now it's time to close that chapter - as of now PHP 5.3 is not supported anymore and the different RM teams and contributors are making PHP even better than PHP 5.3 ever was, as we can see in existing and previews of future releases.
Thank You All, it was a great time!
Mar 12: Future of PHP 6
Yesterday was a quite thrilling day for the PHP development team and led to some imprecise news articles so let's take a look at what happened: Over the last months many of the core contributors agreed that the current approach to bring Unicode into PHP's engine wasn't the right approach and a good thing would be to rethink it from the start. By a provocative move of one contributor the stalled situation got some more movement and Rasmus declared the current implementation to be discontinued to restart.
When the foundation of what should have become PHP 6 was created a decision was made to use UTF-16 as internal encoding for "everything" inside the engine. The choice for UTF-16 was made due to the fact that PHP 6 would use the ICU library which is focused on offering UTF-16 string functions. By using UTF-16 as default encoding we'd have to convert the script code and all data passed from or to the script (request data, database results, output, ...) from another encoding, usually UTF-8, to UTF-16 or back. The need for conversion doesn't only require CPU time and more memory (a UTF-16 string takes double memory of a UTF-8 string in many cases) but makes the implementation rather complex as we always have to figure out which encoding was the right one for a given situation. From the userspace point of view the implementation brought some backwards compatibility breaks which would require manual review of the code. These all are pains for a very small gain for many users where many would be happy about a tighter integration of some mbstring-like functionality. This all led to a situation for many contributors not willing to use "trunk" as their main development tree but either develop using the stable 5.2/5.3 trees or refuse to do development at all.
The presentYesterday the stagnation created by the situation has been resolved and it was decided that our trunk in svn will be based on 5.3 and we'll merge features from the old trunk and new features there so that 5.3 will be a true stable branch. The EOL for 5.2 has not yet been defined but I suggest you to really migrate over to 5.3, which usually can be done with very little work, as soon as possible.
The futureRight now we're starting different discussions to see what kind of Unicode support we really want. Many contributors react positive on a proposed "string class" which wraps string operations in Unicode and binary forms without going deep in the engine. In my opinion such an approach might also be a way to solve some of the often criticized inconsistencies in PHP's string APIs without the need to break old code. (new code uses the new class, old code the old functions) But that idea is far from a proper proposal or even the implementation, current status is about refocusing the development and get the requirement and design discussions going. By that it's a bit early to decide whether the next version of PHP will be called PHP 5.4, PHP 6 or maybe even PHP 7.
PHP is alive and kicking!