Each release has its own folder in data/releases/x.y/x.y.z that contains its metadata, announcements and changelogs.

Adding a release to php.net typically required running a series of CLI scripts, these scripts would:

These went in /releases/x_y_z.php and contained the release announcement that looked something like:

The PHP development team announces the immediate availability of PHP 8.4.22. This is a bug fix release.

All PHP 8.4 users are encouraged to upgrade to this version.

For source downloads of PHP 8.4.22 please visit our downloads page, Windows source and binaries can also be found there. The list of changes is recorded in the ChangeLog.

Crucially, this text was presented as a webpage, it was created as a PHP file that included its rendering for the header and footer. The plain announcement text itself was not stored separately.

This file would need to be committed.

The current code has two files:

• version.inc contains only the most recent versions. This file exists for ease of updating as the RM need only update the version, date, and sha256 tags. An IIFE then mutates this to the same format as:

• releases.inc contains archive of releases for every single version the website tracks. This stores the “final” format, mainly with how it changes the source files array to include the filename, name and date.

When using `bin/bumpRelease x y` it would take the most recent information for the x.y branch from version.inc, transform it into its 'full' form, and append onto the top of releases.inc.

The RM would then update version.inc to include the new hashes.

Both of these files would also need to be committed - The build process will take care of the rest.

The future website concept aims to decouple data from presentation. It aims to store that data, as much as possible, in raw, self-contained, human-readable/editable files.

For releases, instead of manipulating giant arrays, the release data is stored within a directory structure, and a build step compiles that data into whatever form the website needs from it, without the need for further RM involvement.

Calling `php bin/rm/create-release.php --news=/path/to/news x.y.z` will create the following files:

• data/releases/x.y/x.y.z/announcement.html - Contains the raw, unwrapped release announcement html. It will be pre-populated with the HTML you would expect, with version numbers, download links etc prepopulated. It is not expected for there to be a need to edit this.
• data/releases/x.y/x.y.z/release.json - Contains the date, tags and sources. The majority of the content will already have been pre-generated, but the sha256 hashes will need updating.
• data/releases/x.y/x.y.z/news.txt - Contains the extract from the NEWS file in php-src that is relevant to this specific release. It is not expected for there to be a need to edit this.

These are the only files that need to be committed.

By having the data stored separately, we can re-use it, repurpose it, and combine it wherever it is suitable to do so.

Previously the release announcement page only contained the announcement text.

With the future concept, the announcement page will be enhanced to include not only the announcement, but the source code, change logs, and automatic contextual warnings relating to if it is still supported, if there are additional security fixes available on newer versions etc.

Example: https://web-php-revamp26-558551258802.europe-west4.run.app/releases/8_2_20.php

The ATOM/NEWS feed - Not sure how important this is given that we can generate them dynamically, but there's also other news in there such as events.