Hi @YBerllan. I have Meraki switches deployed in 24x7 factory environments. Before I put it into such an environment I tell the customer they must agreement to giving me one outage window every year - which they usually can do (most have some kind of maintenance shutdown).
To make this workable you must stick to "stable" code. Even if you strike a bug. This is because the "stable" train for switches is usually only updated once a year or so (this is not a policy, just an observation). Also Meraki does not make people move from one stable release to another very aggressively - so you usually have quite a time window.
So the "stable" train has a relatively long life in Meraki terms.
Next comes the "Stable release candidate" train. You will be forced to upgrade to newer "stable release trains" as they become available. From my experience, you might be forced to deployed a newer version within 3 months. Maybe 6 months if you are lucky.
I often use this train for "office" environments, where the office can have an outage every night.
Lastly their is the "beta" release train. These have the shortest release cycle. Meraki will force you to upgrade and get off older beta code frequently (maybe within 2 months). Obviously Meraki do not want to keep having to support older beta code.
I only tend to use this code when I have a critical bug that is fixed in the beta code, or their is a new feature that the customer really really wants.
So basically you need to select a "train" based on how tolerant you are to having down time.