For a release like this where the only fix is "General stability and performance improvements", it would be nice to get some additional clarity as to what has been fixed.
Agreed. I have read the documentation:
https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Managing_Firmware_Upgrades
https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Cisco_Meraki_Firmware_FAQ
From what I read, if one upgraded to the most recent stable release candidate, then a new stable (or potentially not-classified-as stable) release candidate being released will only be support with "best effort". Quoth the Release Process documentation: "The latest stable release candidate firmware is fully supported by our Support and Engineering teams. Older stable release candidates are supported with best effort; an upgrade to the latest beta, stable release candidate, or stable will ensure full support. "
To me this suggests that one should absolutely stay away from all release candidates, even if they are labelled as stable, unless (1) there is a very specific known security fix, (2) a device is experiencing a major issue that Meraki support says will be fixed by a specific release candidate, or (3) an organization has enough extra Meraki gear, time and interest in testing release candidates. But to partially address item #1, the documentation says that "Critical updates, such as those to address high-impact security vulnerabilities, may be scheduled on a shorter timeline."
Quoting again from the Release Candidate documentation on the "Stable Release Candidate" section: "These upgrades can be canceled, modified, or reverted using the firmware upgrade tool on dashboard." That seems scary to me, but maybe reverting is easy if one just opens a support case.
I'm happy to be wrong, corrected or exposed to other opinions on the utility/scariness of pushing the Stable Release Candidate to any production (or soon-to-be-production) device.
You can always choose from stable, RC (if one exists at that moment), and beta (again if one exists at that moment). There won't always be RCs or betas as it all depends on code dev cycles.
A recently upgraded network can use the Rollback function within 14 days of the upgrade. Beyond 14 days while the rollback button is no longer available there's nothing to prevent you from manually downgrading back to the stable version.
The only time a Support case would be required is if you want to move to a much older/no longer published version of firmware.
@Ryan_Miles Thank you again for your help. That sounds great, but how does that square with the language I referenced in the Stable Release Candidate section?
"These upgrades can be canceled, modified, or reverted using the firmware upgrade tool on dashboard."
Does the documentation for the Firmware Upgrade Release Process need to be updated to reflect the information you provided?
"These upgrades can be canceled, modified, or reverted using the firmware upgrade tool on dashboard." That is a true statement. I'm not following you on what the gap is.
I completely misread the documentation and am appropriately embarrassed.
That said, I still stand by my comments earlier arguing that almost everyone should stay away from all release candidates, even if they are labelled as stable, unless (1) there is a very specific known security fix, (2) a device is experiencing a major issue that Meraki support says will be fixed by a specific release candidate, or (3) an organization has enough extra Meraki gear, time and interest in testing release candidates. But to partially address item #1, the documentation says that "Critical updates, such as those to address high-impact security vulnerabilities, may be scheduled on a shorter timeline."
I worry that I would be told by support to upgrade/rollback if on a release candidate since "The latest stable release candidate firmware is fully supported by our Support and Engineering teams. Older stable release candidates are supported with best effort; an upgrade to the latest beta, stable release candidate, or stable will ensure full support. "
@K2_Josh from my experience you are often asked to upgrade to the latest stable or stable release candidate by support when there is an issue, if you aren't already on it. I would always advise to go to the latest version that you feel comfortable with. We generally only run stable versions in our main data centre, but do run release candidate and beta versions in smaller sites.