This makes it possible for PHP Monitor to request what the latest
version of Valet is. This isn't wired up to the UI currently, so
this feature isn't enabled yet.
To enable this feature, I would need to add:
- Conditional check for Valet updates (via setting)
- Decide when to run this check (either every X time and at launch)?
Additionally, PHP Monitor should be aware of its own uptime in order
to make periodic checks if the app hasn't been restarted. A check
should ideally occur every week or so if the app is not restarted.
The relevant app update check should also be adjusted to run in a very
similar way. How frequently the app checks for updates might also be
a setting but I don't want to query too often.
If you serve a single folder locally multiple times, e.g. as
`cdn.mydomain.test` and `mydomain.test`, securing would fail
for domain that came alphabetically last.
This has been resolved if you are running Valet 3 or newer by
leveraging the `valet secure $domain` syntax.
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).
