Interview with Peter Kokot, one of the release managers of PHP 7.4

Peter, one of the release managers of PHP 7.4, working at his desk with elePHPant
Development Community

Our developer Peter Kokot is one of the release managers of the upcoming PHP 7.4 release. Even though he has a lot on his plate right now, he was able to take the time to answer a few questions and give us a glimpse into what new features we can expect. Enjoy the read!


1. How did you first get involved with programming, in particular with PHP?

I got involved with programming during my time at university; I’ve been always interested in computers and this hacky, programming stuff. I discovered PHP very soon since it was very popular on the web development scene and so I started building websites with it. 

Back then we were using all kinds of spaghetti code frameworks and some first CMSes such as Mambo (which was then forked and became Joomla!), then we moved to open source frameworks, starting with PHP as early as in version 4. Following that, I started working with PHP more and more - and now here I am. 

With the arrival of GitHub and its impact on open source, I felt very drawn to open source. GitHub allowed people to connect on a totally different level, enabling easier collaboration of people from all over the world; it’s so widespread that people from anywhere on the planet can help and contribute patches to open source projects and this is also how I started contributing to PHP.

This was all on my own initiative; I was very interested especially in the open source framework Symfony which presented a huge leap for PHP and improved the PHP ecosystem drastically. Then I also got more interested in PHP in particular, i.e. the core and what is happening behind the scenes in PHP, and I started submitting patches there as well because I found some bugs and tried to fix them. 


2. How did you then get to the position of a PHP release manager? Did you volunteer?

No, I didn’t volunteer to be one of the release managers. Rather, I got nominated by the PHP internals community members. I do enjoy it, though. This is my first time as a release manager, so I’m still quite a newbie. Some people from the community also jokingly call me “newcomer”.

It’s quite a challenging project. There are established workflows and teams behind it so a lot of knowledge is needed to participate efficiently. On top of that, constructive and quality cooperation to get along with other community members and their workflows is essential.


3. What are the responsibilities and tasks of a PHP release manager?

A PHP release manager works periodically where he or she creates PHP distribution packages (tarballs) for the release candidate (RC) and stable releases every 2 weeks. With each release it needs to be checked if all tests pass and if changelogs are updated, and certain files needed for further compilation from the end users’ side need to be generated. Release announcements also need to be made over the mailing lists with each release. It is a very “long-distance” task, lasting for several years (minimum 3 years for the period of the particular PHP branch support). 

Here, I have to point out that I’m actually one of the two release managers - the other one being Derick Rethans, author of Xdebug, who is more familiar with PHP internals. This week we had our first meeting where we discussed and synced our workflows.

It can however be a very stressful task, since people expect a lot from you for tasks on an open source project. It all depends on people’s free time, because they usually have their daily lives with work and thus need to coordinate their time very well. Of course, the community expects the release to be done on the exact date, and everything needs to work without any problems, so that Drupal and other PHP projects work with the new version as flawlessly as possible.

So, we could definitely say that the role of a release manager entails both the more tech-oriented and the marketing aspects.


4. Did you encounter any challenges with the development of this minor release? What about with version 8.0 which is coming next year?

The 7.4 version is a minor, less important and mostly a boring release - this is good because upgrades will also be very simple from previous PHP 7 versions. The next major release, PHP 8.0, will have a bigger impact but it’s not yet certain which exact new features will be included, because the plan contains many of those which the community isn’t yet familiar with.

For PHP 7.4, however, there have been a lot of new features, e.g. the integration of the FFI (Foreign Function Interface) extension - a completely new extension. FFI opens up a new, broader world to PHP besides web development. For example, machine learning and similar. There are still some bugs though so it is still marked as experimental. It should get stabilized over time before the PHP 8 release.

So, with the current plan, on June 13th we’ll see the first alpha version of PHP 7.4. This one won’t be a feature freeze milestone yet. That one is planned for July 23rd. Up until that point we can include new features, not only bug fixes, but also new functionality.

This is where RFCs (Requests for Comments) come in. An RFC is a document for proposing changes to the PHP language.

The RFC process includes discussing a request on the mailing list and then it goes to a voting phase for 2 weeks if the initial feedback looks promising. So, for example, less than two weeks before the feature freeze we can no longer expect the RFC to appear in the PHP 7.4 version. In this case, it should then target the PHP 8.0 release.

In PHP, while this is an official process, someone who has been involved with a project for a very long time might still veto a certain RFC. This is something that happens very rarely though, but it did happen with one of the RFCs targeting the 7.4 release (deprecation of the short opening tags) - the community might not be super happy about it, but let’s see what comes out of it. There might still be other ways of solving this using a different deprecation way and future changes.


5. Besides the stuff we already discussed, what other new features can we expect in next month’s release? What about in PHP 8.0?

The 7.4 version actually has a lot of new features; they’re also listed here. There are some backwards incompatible changes which means that code will need to be tweaked a little in some cases. Strictly speaking, minor versions shouldn’t contain any backward incompatibilities. These should happen in the major release. However PHP seems to allow minor BC breaks here and there, so the language can progress further.

Besides the previously mentioned new FFI extension, an interesting new feature is preloading. It means loading PHP classes or functions directly into the memory. When you run the program, it works faster compared to usual autoloading approaches. This is a relatively small but important feature as it has long-term potential to be used instead of the autoloading in certain cases.

There are a ton of new features and some extensions were removed since they are no longer properly maintained. Typed Properties is another big thing, very useful for object-oriented programming.

One of the major new features in the next major release PHP 8.0 will certainly be JIT - Just-in-time compiling. It was planned for the 7.4 release but based on the RFC voting it was decided it’s still a bit too early to release it and more time is needed for thorough testing. It’s quite a different concept of compiling PHP code internally and in combination with the FFI extension it enables some really cool stuff because it opens up a whole new world of possibilities to PHP beyond just the web. 


6. What does it mean to you that the community has selected you as one of the release managers for this version?

It’s a very interesting role, so it’s interesting also from the point of view of experience and a chance to see how other open source projects are run, and most of all a chance to directly help out PHP the best I can.

I’m definitely happy with being chosen. In fact, I must admit that in the beginning it was mostly other people that were proud, but I quickly realized that this really is a big thing. You have to put a lot of work into it. Performing a task at specific times of a month is very very very exhausting; luckily, there are a number of people who feel very at home doing this, they can help out or even fill in. E.g. someone who’s an expert in a certain field can step in, so for example a 7.2 release manager can help out with the 7.3 release if someone goes on vacation, has to take a leave or something like that.

The new version has to be released, but there are of course human errors, it takes a lot of synchronization and good communication, as well as getting along with other people working on the project - if you don’t get along, you can’t collaborate effectively. 


7. Now that you’ve broken the ice, do you think the community will nominate you to be the release manager of a future release, maybe even a major one? Do you perhaps even plan on volunteering?

I’ll definitely continue contributing to PHP the best I can. I see PHP’s progress more through the extensions and PHP libraries contributed by the community, not so much through the core. I think the entire community is a vital part of PHP to function as it should and to be a successful language further on.

Oh, next week we’re hosting a local PHP meetup in our offices in Ljubljana, where I’ll also be presenting an interesting PHP topic, i.e. the upcoming PHP 7.4 version - you guessed it, right? :) It'll be a short presentation about the features of PHP 7.4, how to upgrade and what to expect. I’ll also briefly explain some PHP internals things. We’ll do our best to make it fun and interesting. :)


Herd of elePHPants in Agiledrop offices