Right now, the WP-CLI default updating mechanism will look at whether the latest available release is newer than the currently installed one and offer to update to that new version (in interactive mode or when triggered via wp cli update).

This creates a problem when we raise the PHP minimum version. Let's say we bump the PHP version to 7.0+ with WP-CLI 3.0.0. On a system running on PHP 5.6, it will see that 3.0.0 is available and propose to update. When the user confirms this, the update will just break and it will revert to the already installed version. But the notice will not go away to install 3.0.0 (or any subsequent version), as WP-CLI does not check the PHP compatibility for available updates.

Another problem is that, if you are running on 2.12.0 and you cannot use 3.0.0, you can also not easily get security updates. If we'd push a 2.12.1 security hotfix, the updater would still only see 3.0.0 and try to update to that.

I suggest two separate changes:

1. always update to the latest non-major first before trying to update a major. So, in the above case, the updater would first update to 2.9.1, before attempting to update to 3.0.0. This will ensure that we have ways of reaching all major versions with security patches or updater fixes.

2. think about how best to add PHP requirements into the updater process so that the update is not even being considered when it is known to not be compatible. You should still be able to override this, of course, as the PHP version you are running for updates is not necessarily the same you use to run WP-CLI against a given site. But the default behavior should be safe enough to never fatal out or get stuck in update notifications you cannot get rid of anymore.