Please do not skip versions during upgrades. We have been using a two-version deprecation cycle, so a protobuf field that existed in 0.22.1 may no longer exist in 0.24.x, meaning that a direct live upgrade could cause masters and agents to stop communicating with each other. We only guarantee live upgrades from one version to the next minor version (e.g. 0.22.x->0.23.x), so the recommended procedure is to follow the linked upgrade guide to upgrade the entire cluster (even the libmesos for schedulers/executors) to the next version, then repeat the procedure to upgrade the entire cluster to the following version and so on. The usual process is to upgrade masters first, then agents, then schedulers and custom executors. There may be other caveats listed in the upgrades guide that indicate deprecated/removed endpoints, formatting/behavior changes, etc.
Now that we've moved to a more monthly release cycle, we will be extending our deprecation cycle to ~6months/versions, so that you could skip versions in the future. Once we reach 1.0, we'll have stronger guarantees about upgrading minor versions within 1.x. On Wed, Dec 9, 2015 at 7:39 AM, tommy xiao <xia...@gmail.com> wrote: > Hi Alex, > > I think you need review the mesos upgrade docs. > > http://mesos.apache.org/documentation/latest/upgrades/ > > > > 2015-12-09 23:04 GMT+08:00 <aaa...@gmail.com>: > >> Hi All! >> >> We have running cluster with mesos 0.22.1 and marathon 0.8.2 running on >> it. >> Is it safe to upgrade directly 0.22.1 --> 0.25.0 without installing >> intermediate versions? >> >> How i can perform rollback if something went wrong? Would installing >> previous versions just do the job? >> >> -- >> Alex Griazin >> > > > > -- > Deshi Xiao > Twitter: xds2000 > E-mail: xiaods(AT)gmail.com >
