Interview With Eric Mann Release Manager PHP 8.3 In this episode, Scott talks with Eric Mann about his experience as one of the PHP 8.3 Release Managers and writing his book PHP Cookbook. Note: this transcript was transcribed by AI and then edited for clarity. Scott Keck-Warren: Hello developers, and welcome to the php[architect] community corner, where we have conversations with members of the web development community. I’m your host, Scott Keck-Warren, and today we’re talking with Eric Mann about being a release manager for PHP 8.3 and his new book PHP Cookbook. Eric Mann is a well-established cybersecurity, software, and infrastructure engineer, having led multiple teams of various sizes in the private sector. Eric has experience architecting highly-available and resilient SaaS platforms, scalable e-commerce websites, and industry-defining AI/ML operations. In addition to leading technical teams, Eric frequently lectures at events on both scalable engineering and cybersecurity. He also publishes books on programming and secure software design. Eric is a member of both ISACA (Information Systems Audit and Control Association) and OWASP (Open Worldwide Application Security Project) and is a release manager for PHP 8.3. I wanted to start out today and ask you about your experience as one of the release managers for PHP 8.3. Eric Mann Okay. Cool. Yeah. The experience has been fantastic thus far. It’s been a really supportive community, making sure that we get everything taken care of as quickly and as reliably as we can. One of the things that is really interesting, I did not understand the PHP release process before I started this. I knew we had release managers. I knew we had a release process, but I didn’t really understand what it looked like. So understanding that we cut the release or package the release on one day. On the next day, people will bundle the release for various distributions, and then on the third day we will announce it actually made me feel a lot better just knowing that everybody works from very disparate time zones. And I was really concerned about calendar coordination. So one of the biggest things I learned was both what the release process looked like, but also just how well suited it is for asynchronous operations and remote work. The fact that I am on the US West Coast and the rest of the release managers are not even in the US, it’s been amazing to coordinate with folks across borders and make sure that we can do things both across borders and across time zones. And as far as how seamless things are from the outside perspective, you can’t tell. Everything is just nice and smooth, and the operation moves forward perfectly well. And I think that’s been amazing and fantastic to learn and see from the inside. Scott Keck-Warren: So it kind of sounds like the whole process is set up to be asynchronous. Eric Mann It very much is. The way things will typically work is in a release week at some point in time on Tuesday, you will build the release, make sure everything is ready to go, tag the release and then email to tell everybody, hey, the release is ready. Please go ahead and run your builds for Debian and other operating systems, Windows and whatnot. Sometime on Wednesday, the builders will run their builds and say, hey, here are the builds. They’ll check to see if anything unexpected happened and then let people know where the builds live. And then on Thursday, at some point in time, the release manager will go through and post the announcement for the release, showing where the hash checksums live, where the signatures live, where the binaries live, and all of the compressed artifacts. But all of these happen at different times and everything’s coordinated completely asynchronously via email. I have now personally managed releases from three se...