PHP Monitor 25 will use a new numbering scheme, following the format:
25.06 = 25 . 06 . 0
M m p
(Minor, minor and patch.)
So what was supposed to be PHP Monitor 7.3 will now be version 25, with
the minor version number decided by the release month.
The cut-off date for PHP Monitor 7.2 is currently 2025-11-30, so I have
time but I'd prefer to have two releases out this year:
- One release migrating to the new numbering scheme
- One release with full support for macOS 26
Since I plan on only doing maintenance releases with no patches except
when bugs pop up, the major/minor version notation combination should
suffice.
With this release, the minimum supported version of macOS will become
macOS Ventura 13.5.
That means that support is dropped for Monterey and Ventura's older
builds. Since Homebrew is also changing with built-in service management
I think it's time to drop support for these older versions of macOS,
which I no longer intend to test for.
Older versions of PHP Monitor will, of course, remain functional, but
since Homebrew is an ever-changing thing, I cannot guarantee nothing
will break in those older versions with the newer API.
Thankfully, these changes are simple. Before releasing, I will be
testing the new build, though.
Here's what constants I changed, and why:
- Homebrew PHP formulae are now consistently sourced from the
`shivammathur/php` tap. This should make the transition to new PHP
releases a little bit easier, but I need to verify this works without
issues before publishing this update.
- Bumped the PHP formulae cutoff date to Nov 30, 2025.
At this point, PHP 8.5 should be released.
- Added support for pre-release (daily) versions of PHP 8.5.
The self-updater is now a requirement for the main app to be able to be
built. You no longer need the existing binary. This makes it easier for
anyone to just try out the app locally and makes reproducible builds
also possible.
(This is done because the self-updater code will soon be moved to a
separate package, and I want to make this entire updater process
as simple as possible.)
In order to avoid the self-updater app from appearing as a product when
archiving a build, SKIP_INSTALL is set to true. This avoids a variety
of annoying issues including the archive appearing under "Other Items".
- Chinese translations contributed by @guanguans (via #285).
- Updated the credits so that all translators are now also listed
separately, since the GitHub issue has been closed.
- Make spinner view opaque to hide incorrect info
when refreshing PHP installations
- Resolve each PHP installation to a Homebrew version
- Fix an issue where certain PHP upgrades don't show up
In this build, resolving PHP upgrades happens based on the formula name.
This avoids issues where available PHP version upgrades would *not* be
detected correctly (based on the installed version).
This commit introduces a new diagnostics feature which is executed
when the app boots. When the app boots, the integrity of the PHP
symlinks are checked to ensure that all symlinks correctly link to
a valid PHP version. If any links to an incorrect PHP version,
then those outdated or incorrect symlinks will be removed.
For example, if `php@8.2` links to `../Cellar/php/8.3.0` then that is
an obvious reason for that symlink to be purged because it links to
the incorrect version. (This example behaviour has been noted in #270.)
This occurs prior to the rest of the startup process, so this way
no incorrect PHP versions can pop up in the version switcher, and
no incorrect PHP version is reported as being installed when
managing installed PHP versions.
In order to make this possible, I've added a new `sync()` method to the
Shellable protocol, which now should allow us to run shell commands
synchronously. Back to basics, as this was how *all* commands were
run in legacy versions of PHP Monitor.
The advantage here is that there is now a choice. Previously, you'd
have to use the `system()` helper that I added.
Usage of that helper is now discouraged, as is the synchronous
shell method, but it may be useful for some methods where waiting
for the outcome of the output is required.
(Important: the `system()` helper is still required when determining
what the preferred terminal is during the initialization of the
`Paths` class.)
