%201.png?width=302&name=Netgate%20Logo%20PMS%20(horizontal)%201.png "NetgateColorLogoRegisteredRGB.png")
We are moving the version of PHP used by pfSense® software to PHP 8.1. We have also taken a decision to move the base operating system version of FreeBSD used by pfSense software from 12-STABLE to the current development “top of tree” version also known as “main”, or “HEAD”, and, at the time of writing, “14-CURRENT”.
In order to minimize potential disruption to the community and customer base, public development snapshots and repository synchronization have been temporarily paused while we work on these major shifts, including internal testing of builds.
Moving to PHP 8.1
Recent releases of pfSense software have been based on PHP 7.4, which is now approaching its EOL date in late November. We are migrating the version of PHP used by pfSense software to PHP 8.1, skipping over the interim 8.0 release. This means we will be on the latest available release of PHP. PHP 8.1 is supported upstream until late 2024.
Getting to PHP 8.1 means working through issues with the pfSense software codebase that involve items deprecated (8.0, 8.1) or changed (8.0, 8.1) between PHP releases. Work is ongoing to address these issues, including changes to our PHP module code and fundamental changes to how PHP code can access and change configuration data in a more robust way. Some of these changes may not be backward compatible with PHP 7.x, so take care when copying code from the current repository contents onto older installations. Package maintainers may also need to account for these changes in their packages.
We have information on these PHP development changes available in the documentation for community developers and package maintainers.
Why move to FreeBSD main?
Skipping over FreeBSD 13 and using the main development branch of 14 isn’t about avoiding an unlucky number (though some have suggested this could be considered a side benefit!). Following the main branch gives pfSense software access to the latest features added to FreeBSD. When new features are added to FreeBSD, developers merge them into the main branch first after review. Similarly, FreeBSD development work is focused on the main branch for other items such as the latest bug fixes, errata fixes, security fixes, and other corrections.
When support for new hardware is added to FreeBSD, it goes into the main branch first. Tracking the main branch of FreeBSD gives pfSense software the most up-to-date drivers for a variety of hardware.
Having the primary development branch of pfSense software track the primary development branch of FreeBSD aligns us closer to the development cycle of FreeBSD so we are both developing our future versions against similar branches. Dealing with changes as they arrive in the FreeBSD main branch also helps avoid more complex and larger volumes of work any time pfSense software should change to a newer FreeBSD base.
Furthermore, as Netgate® continues to upstream our own custom changes to FreeBSD, we can take advantage of these submissions while lowering our technical debt.
Finally, the stable/13 and main branches of FreeBSD have not diverged heavily, which speaks volumes to the stability of the main branch. Developing against the main branch allows us to address potential incompatibility issues as they arise instead of having to address them in larger batches between “stable” releases.
pfSense Plus and Community Edition
We are making these changes on the development branches of both the Community Edition and Plus versions of pfSense software. The changes will show up in snapshots of both once initial development stabilizes.
Development of both pfSense Plus and CE is continual and ongoing. The next planned release is pfSense Plus version 22.11, scheduled for November of this year.
Noteworthy Considerations
FreeBSD makes an effort to maintain compatibility between kernels and kernel modules, such as those from packages, built on versions of FreeBSD in the same major version. This binary compatibility is due to the kernel ABI/API not changing often, if at all. In this way the ABI/API is "stable," hence the use of that term in FreeBSD branch names. Following the main branch of FreeBSD can introduce more rapid changes to the kernel ABI/API, but this is not a concern at all for pfSense software. Each version of pfSense software is built as a whole set of base and add-on packages all from the same source at the same time, and Netgate does not offer binary packages compatible with multiple versions.
Following the main branch opens up the potential possibility of bringing in breaking changes as development occurs in FreeBSD. Though this is possible during development, it is not a factor for releases as we can always choose to omit these changes or branch the pfSense release off main from an earlier point near the end of development for a particular pfSense software version. Netflix runs their systems off FreeBSD main in a similar fashion, from points a few weeks behind the latest code, and they hold off on updating if there is a breaking change upstream.
In the past, the main branch of FreeBSD gained a negative reputation for frequent disruptions, broken builds, and other similar problems. This has vastly improved over time with changes undergoing more thorough review before being introduced even into the main branch. Even so, as with the previous point, should such a problem arise and be a blocking issue, we can base the next pfSense software release off an earlier point on the branch.
Netgate has been releasing pfSense software versions based on points along the 12-STABLE development branch for the last three and a half years instead of using specific FreeBSD releases, and this has been working well. As such, concerns about running code from FreeBSD development branches are not significant. Some company policies may not agree with the labeling of the FreeBSD base OS as a "development" version when pfSense software is labeled a release, but such problems would have been an issue on 12-STABLE as well since it is also a “development” release.
Rather than having multiple releases, or potentially years, between having to announce that a function is deprecated and when it is removed from FreeBSD, it may be removed immediately upstream. For example, 3DES is deprecated in FreeBSD 14 and will no longer be supported by IPsec in releases based on that version. Netgate can evaluate these on a case-by-case basis. If we find that it is appropriate to meet the needs of customers, we can choose to take on the technical debt of maintaining such functions independently for a period of time as customers plan phasing out deprecated features.
Summary
We feel that moving to development against the main branch is the correct path for future development. We feel that the benefits far outweigh the risks, most of which are either not relevant to pfSense software or are easily mitigated.