# php-src: one default branch, three release lines, and a build that starts at buildconf > php-src is the C source of the PHP interpreter, and its README is a build manual rather than a product page: dependency lists per platform, configure flags for development against production, a parallel test suite, and a contribution process where new features need an RFC. The detail that matters to a team is that three supported branches were patched on the same day, so the version you build is a decision, not a default. **php/php-src** — GitHub describes it as The PHP Interpreter. The repository metadata lists C as its primary language. The metadata lists the BSD-3-Clause license. This article stays within the project description and details documented in the GitHub repository README. - Repository: https://github.com/php/php-src - Website: https://www.php.net - Stars: 40,425 · Forks: 8,156 - Language: C - License: BSD-3-Clause - Published: 2026-08-13 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/php-php-src ## Three release lines, all patched on 2026-09-24 The releases tell you what support looks like here. php-8.5.11, php-8.4.26 and php-8.3.35 were all published on 2026-09-24, three separate lines receiving patches on the same afternoon, and the last push to master was on 2026-09-28. The repository is not archived, and the licence is the Modified BSD License, SPDX BSD-3-Clause, with the LICENSE file at the root. The practical reading is that three minor versions are maintained at once, so a security or correctness fix may need to land three times, and a team pinning a version has three supported choices rather than one. The default branch is master, which is the integration line rather than a released version, so the source of record for what you are shipping is a tag. The README does not name which version master is currently heading towards, so if that matters to your build, read configure.ac or the NEWS file rather than guessing from the branch name. ## A minimal build and a default build need different dependencies The dependency list is split, and the split is the first thing to get right. For a minimal build from Git you need autoconf, bison and re2c. For a default build you additionally need libxml2 and libsqlite3. On Ubuntu: ```shell sudo apt install -y pkg-config build-essential autoconf bison re2c libxml2-dev libsqlite3-dev ``` On MacOS with Homebrew: ```shell brew install autoconf bison re2c libiconv libxml2 sqlite ``` The README also gives a Fedora line with dnf and a MacPorts line with port. Note that the Homebrew line installs libiconv, which the minimal list does not mention, and that the Ubuntu line leads with pkg-config and build-essential. So the commands are per platform as well as per build type, and the README does not enumerate which bundled extensions each of those libraries switches on, which means a minimal build is a smaller interpreter than a default one and the difference shows up at runtime rather than at configure time. ## buildconf, then a configure line that decides what you get There is no configure script in the repository, so the first build step generates one: ```shell ./buildconf ``` Then the configure line is the decision that matters, and the README gives two of them side by side: ```shell # For development ./configure --enable-debug # For production ./configure ``` `--enable-debug` is the recommended setting for development, and `./configure --help` holds the full option list. A development build and a production build are therefore different artifacts, not the same artifact with more logging, and the flag is baked in at configure time, so switching means reconfiguring and rebuilding rather than changing a runtime setting. Compilation is plain make, and the README says to set the job count to the number of cores, which `nproc` will tell you: ```shell make -j4 ``` ## make test spawns up to ten workers unless you say otherwise After a successful compile, `make test` runs the suite, and the default parallelism is machine-dependent: tests run in parallel using up to 10 detected logical processors. The worker count is overridable through `TEST_PHP_ARGS` or `TESTS`: ```shell make TEST_PHP_ARGS=-j4 test ``` The same variables scope the run. `-j1` makes the suite sequential, which is what you want when a failure is intermittent or when a debugger is attached, and naming a directory limits the run to that part of the tree: ```shell make TESTS=tests/lang/ test ``` Two things follow for CI. A default `make test` on a large runner will start ten concurrent workers, so a memory-constrained container needs `-jN` set explicitly or it will be the parallelism that fails first. And because the default is derived from the host, the same commit behaves differently on a 32-core build machine and a 2-core container, which makes a green run somewhere other than your CI less conclusive than it looks. qa.php.net carries the per-commit test status. ## PIE replaces pecl for third-party extensions Extensions split into two groups. PHP consists of many essential bundled extensions that live in the tree, and additional extensions come from elsewhere: the PIE Extensions list on Packagist, installed with PIE, the PHP Installer for Extensions, or the PHP Extension Community Library, PECL, which the README calls deprecated. That sentence is the whole migration story for anyone following an older tutorial. A page that tells you to run `pecl install` describes a path the project now marks as on the way out, and the registry of installable extensions is Packagist rather than the pecl.php.net list, so tooling and mirrors built around the old registry are working from a source the project no longer points at. The repository also carries an EXTENSIONS file at the root, but the README does not use it to enumerate the bundled set, so the boundary between what is bundled and what you install is something you establish by reading configure.ac rather than by reading a list. ## Features need an RFC, fixes need a ticket number in the message The contribution rules are asymmetric on purpose. New features require an RFC and must be accepted by the developers, with the process documented on the PHP wiki. Bug fixes do not require an RFC, but they do require the ticket in the commit message: `GH-NNNNNN` for a GitHub issue and `#NNNNNN` for the old bugs.php.net tracker, with the two examples the README gives being `Fix GH-7815: php_uname doesn't recognise latest Windows versions` and `Fix #55371: get_magic_quotes_gpc() throws deprecation warning`. So a patch is cheap to propose and a feature is not, and the barrier is a vote rather than a review. Discussion happens on GitHub, with internals@lists.php.net taking topics that suit a mailing list, and merging follows the Git workflow documented on the wiki. In practice that shapes what arrives from outside: fixes, tests and documentation, because a new function needs a written proposal and a quorum before anyone writes the C. ## Zend/, main/, ext/ and sapi/ are the architecture in four names The root of the repository is the interpreter's own layout, and the names are the map. `Zend/` and `main/` hold the engine and the core, `ext/` holds the bundled extensions, `sapi/` holds the server APIs that embed the interpreter in a web server or the CLI, and `win32/` and `TSRM/` are the Windows and thread-safe runtime pieces. Around them sit `tests/`, `build/`, `scripts/`, `benchmark/`, `pear/`, `docs/` and a `docs-old/`. The rest of the root is operational, and it is worth reading as a list of what the project expects of itself: `configure.ac` and the two `buildconf` scripts, `php.ini-development` and `php.ini-production` as the shipped templates with no `php.ini` committed, `run-tests.php` and `run-extra-tests.php`, `NEWS`, `UPGRADING`, `UPGRADING.INTERNALS`, `SECURITY.md`, `CODING_STANDARDS.md`, `CONTRIBUTING.md`, and two CI directories, `.circleci/` and `.github/`. Two agent instruction files, `AGENTS.md` and `CLAUDE.md`, sit alongside them, which tells you something about how work on this codebase is being done now. ## Conclusion Build from php-src when you need a version, a patch or an extension combination that the prebuilt packages do not give you, and follow the README literally: install the dependency set that matches your build, run ./buildconf, then choose ./configure --enable-debug for work or a plain ./configure for a production artifact, and pass -jN to make when your machine has cores to spare. Do not build from the default master branch when you mean a released version, because master is the integration line and the released sources are the php-8.3.35, php-8.4.26 and php-8.5.11 tags, all patched on 2026-09-24. Before you start, read the UPGRADING and UPGRADING.INTERNALS files for the branch you pick, and check qa.php.net for the test status of that exact tag. ## FAQ ### Where can I find the source code for PHP? It is the php/php-src repository, licensed under the Modified BSD License with the SPDX identifier BSD-3-Clause, and the README calls it the source for the interpreter with contributions handled by forking and sending a pull request. The manual itself is at php.net/docs, and the homepage is https://www.php.net. ### Is PHP open source? Yes. The README states that PHP is distributed under the Modified BSD License and names the SPDX identifier as BSD-3-Clause, with the LICENSE file at the root of the repository. It also documents a contribution path: fork the repository, send a pull request, and use the developer mailing list internals@lists.php.net where a topic suits it. ### Is PHP getting outdated? The repository is not archived and the last push to master was on 2026-09-28, with php-8.5.11, php-8.4.26 and php-8.3.35 all published on 2026-09-24, so three minor lines are being patched at once. The README does not say how many people use PHP, so it cannot answer the adoption part of that question. ## Sources - [Official documentation](https://www.php.net) - [Official README](https://github.com/php/php-src#readme) - [Project repository](https://github.com/php/php-src) - [Release notes](https://github.com/php/php-src/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/php-php-src