Release Notes in a Consistent Location

[Arcturus]

I was partway through deploying 3.0.256 (Master) to the dozen PW sites I manage when I saw there's now a 3.0.257 (Master).

What's the difference? NO IDEA

I checked the website, the blog, the forums, GitHub... because the clues are typically never in the same place or format, and there's not a single sentence describing what's new.

Is it the same as 3.0.257 (Dev), but proven? NO IDEA

Should I start my process over? NO IDEA
 

I appreciate that no one likes doing documentation, but this has been an issue for years, and I'm not asking for much. Looking at LightSpeed Web Server, they have a basic, designated page that gets a low-effort bullet list with every release. This would suffice for the majority of us. Missed a few versions? You can get the gist of things within a couple of minutes. It should live within the Download section of the main website.



It would be even better if someone circled back later and linked to a blog, forum, API doc, etc., if elaboration is available for a bullet point... but I'll take what I can get, as long as it's better than the current ad-hoc approach.

[elabx]

Agree! Maybe it could be automated with GitHub actions? Something that at least gets a list of commits?

[Peter Knight]

It’s a very simple task these days too. I have all changelog and release notes created automatically via a loop. With a few editing guidelines and some samples, it pretty much runs on auto pilot.

Finish feature > automation script reads > rules etc

[Arcturus]

At the very least, going from 3.0.255/256 to 3.0.257 is replacing the following:

1.0.3 => 1.0.4: SessionLoginThrottle
1.0.4 => 1.0.5: ProcessForgotPassword

Of course, halfway through my migration to 3.0.257, there's now a 3.0.258. =S

Update: Going from 3.0.257 to 3.0.258 doesn't trigger any module updates, so no idea what's incorporated in this latest update.

[BrendonKoz]

For project updates, you can always visit the repository on GitHub and check the release tags' commits.

That said, it's not a summarized, itemized, human-readable list, which I believe the request is for, and would be a nice-to-have. And, I would think, definitely something that Claudette and the team could do.

[Kiwi Chris]

I think it would be useful having a consistent location for documentation features both in the open source part and pro modules, and at what version a given feature was introduced.

Sometimes releases are just bug fixes, and depending on what they fix, may or may not be necessary if they're fixing a newer feature that you're not yet using.

I use Plesk on my server, and I like the change log they release. It's colour coded with each release for bug fixes, new features, improved functionality, and deprecations, and though it's a long page to scroll through, you can scroll back and see exactly when a feature was introduced or updated. Something like this would be great.

I've missed or forgotten about new features as they've got mentioned in a blog post at a time I didn't need them, then later when they'd have been useful, I didn't remember they were there.

Documentation for some of the pro modules can be scattered around, and particularly for fieldtypes, but also other pro modules, I think the documentation should live with the main documentation, and might even result in more sales as a result. I think there should be a list of all official fieldtypes, free, and pro, in the documentation section.

There's no single point of reference for everything ProcessWire does. 

The Pro fields seem to be partially included in the API reference, but this is only the API definitions, not general instructions on how to use them.

 

[Peter Knight]

Snap @Kiwi Chris. I view these often too.

Here’s the Plesk colour coded change log. 

 

[Peter Knight]

On 8/28/2026 at 9:54 AM, Kiwi Chris said:

I use Plesk on my server, and I like the change log they release. It's colour coded with each release for bug fixes, new features, improved functionality, and deprecations, and though it's a long page to scroll through, you can scroll back and see exactly when a feature was introduced or updated. Something like this would be great.

Just implemented a similar concept in my own changelog.
https://www.peterknight.digital/docs/mediahub/v1/changelog/