I'd like to inject a word of caution here, in favor of doing both peers during the same maintenance window
If you upgrade a member to a +1 major release, the upgraded member will go into 'nonfunctional' state which means it will take on a passive role and only assume the active role if the not-upgraded member goes down or is suspended. if you intend to 'test' this OS for a while you'd need to manually suspend the not-upgraded peer
if you upgrade one member +2 major versions, it will go into a forced suspend mode that you cannot recover from unless the other member is down, and then you can manually activate (unsuspend) it. so for this to run for more than a few minutes, you'd have to shut down or disconnect your other member
reverting one upgrade down can be easily achieved by running `debug swm revert` + `request restart system` from CLI (because the previously installed OS is maintained on an inactive disk partition), going down further requires a software install
protip on the upgrades: unless you're working on an old hardware, you can download the base image, download the maintenance version, and then directly install and boot into the latest maintenance release for a major version (e.g. 10.0.x directly to 10.1.9). even for the 'inbetween' version i'd recommend going to the latest maintenance release immediately as you don't want to get snagged on a bug mid upgrade
... View more