What problem does this address?
WordPress loves auto-updates; Headless apps that rely on a strongly-typed schema, not so much.
As we get closer to closing out the non-breaking backlog and start on a v2.0, we should consider a way to enforce SemVer on the WP backend.
What is your proposed solution?
At a bare minimum, we should disable automatic updates for X.y.z releases, and place some sort of notice/confirmation dialog when trying to update the plugin manually to a major version in the background.
Ideally, we would take this a step further, and let users (either by filter or by admin setting) set a different autoupdate policy (E.g. only autoupdate x.y.Z versions).
As a bonus, we could even let users opt-in to a beta/next channel, as (based on the gh issue tracker), there's a lot of fundamental/breaking work we have slated for v2.
Major stretch goal would be to allow WPGraphQL extensions to provide a tested up to label, so we could also warn about possible incompatibilities with a new major release.
I would recommend implementing this well before we start work on v2, so there can be a series of releases to ensure there's no kinks before game-day.
What alternatives have you considered?
No response
Additional Context
What problem does this address?
WordPress loves auto-updates; Headless apps that rely on a strongly-typed schema, not so much.
As we get closer to closing out the non-breaking backlog and start on a v2.0, we should consider a way to enforce SemVer on the WP backend.
What is your proposed solution?
At a bare minimum, we should disable automatic updates for X.y.z releases, and place some sort of notice/confirmation dialog when trying to update the plugin manually to a major version in the background.
Ideally, we would take this a step further, and let users (either by filter or by admin setting) set a different autoupdate policy (E.g. only autoupdate x.y.Z versions).
As a bonus, we could even let users opt-in to a beta/next channel, as (based on the gh issue tracker), there's a lot of fundamental/breaking work we have slated for v2.
Major stretch goal would be to allow WPGraphQL extensions to provide a
tested up tolabel, so we could also warn about possible incompatibilities with a new major release.I would recommend implementing this well before we start work on v2, so there can be a series of releases to ensure there's no kinks before game-day.
What alternatives have you considered?
No response
Additional Context
auto_update_{type}hook