mapping between firmware dot releases and version number of builds

[K2_Josh]

For at least MX (and some MR) firmware, releases (defined as a set of features) are published at the dot level (e.g. 30.1 instead of 30). However, it is unclear which firmware build numbers map to the dot releases (e.g 30.0 vs 30.1). I would expect that the dot release would be part of the build number (e.g. it should be 30.1.1234.5 instead what we have now which would be 30.1234.5). To be clear, my recommendation would be to include the dotted release number in the build number.

The Firmware FAQ does not explain this, nor do the release notes that one can page through from the Firmware status page.

One impact of this is that it's not obvious which firmware features should be available for a given firmware upgrade (if it is not on the latest build number within the non-dotted version number). This is true when looking at the "Current Firmware" column in "schedule upgrades". But this is also just generally confusing.

I would like to know if others have encountered confusion regarding this or have figured out ways to compensate for the confusing version numbers for firmware releases distinguished by dotted numbering.

[RaphaelL]

Hi ,

The firmware versions are based on the Semantic Versioning 2.0.0 : https://semver.org/

also stated in : https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

I know that you can't get the full build version via the API , but you can via the dashboard. Which could help to reduce the confusion

[K2_Josh]

@RaphaelL Thanks for your help!

I should have used the terms major and minor version numbering in my question but blanked on the terminology.

I'm still left with the original question: How can one map a build number to a minor release number since the build number only contains the major release number?