The way the testing classes are built with the singletons currently
prevents various test structs from being run at the same time.
I've adjusted the tests in the PHP Monitor EAP test configuration so
that they are not executed concurrently. This does slow down the test
suite but prevents odd crashes from individual tests interfering with
other tests.
It's not an ideal solution and I would like to address this in the
future, but I suspect this will be rather cumbersome. Since the app
does not actually suffer from this particular issue, this is something
worth investigating later.
I will be building my own back-end for custom analytics. I will ensure that no private information is ever sent, only counts of which features are being used will be sent.
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.
