Nice catch! Yes, that version definitely has a mig...
# spicedbj
jzelinskie
05/01/2023, 8:34 PMNice catch! Yes, that version definitely has a migration for MySQL and Postgres users that is required. You should be able to upgrade from v1.9 to v1.13 by running the migrations for v1.13, but note that there are also backwards incompatible changes to dispatching that can cause downtime in those versions, too.
a
amanda248
05/01/2023, 8:49 PMGreat thanks for confirming! What are those backwards incompatible changes you're talking about?
j
jzelinskie
05/01/2023, 8:50 PMv1.13 contains a change to the internal dispatch API, which means that v1.13.0 and v1.12.0 can not dispatch to each other during a rolling upgrade. To upgrade without downtime, run these as separate Kubernetes services, or disable dispatch before upgrading.
v1.11 contains a change to the internal dispatch API, which means that v1.10.0 and v1.11.0 can not dispatch to each other during a rolling upgrade. To upgrade without downtime, run these as separate Kubernetes services, or disable dispatch before upgrading.
You're free to jump from v1.10 to v1.13 and do this A/B deployment once instead of twice.
jzelinskie
05/01/2023, 8:51 PMIf you don't mind a bit of downtime, you can just shut everything down and run the migrations all the way to the latest release and spin it back up
a
amanda248
05/01/2023, 11:31 PMI see. For context, we're eventually trying to upgrade from 1.9 to 1.20. And I saw in the 1.14 release notes that we have to upgrade to 1.13 first, and can't skip all the way to 1.20?
amanda248
05/01/2023, 11:31 PMbtw I saw you updated the 1.10 release notes to mention the migration, thank you 👍
j
jzelinskie
05/02/2023, 3:04 PMYep, you should jump to v1.13 first then all the way to v1.20
jzelinskie
05/02/2023, 3:04 PMI believe some migrations got squashed because of large changes in how Postgres works in v1.14
a
amanda248
05/02/2023, 5:22 PMok great
amanda248
05/02/2023, 5:29 PMand are the datastore migrations required for a new version generally backwards compatible to the previous version (unless otherwise mentioned)?
e.g. to upgrade from 1.9, I should run the datastore migration first. Would that break 1.9 (meaning i have to roll out 1.10 immediately)?
j
jzelinskie
05/08/2023, 4:55 PMFor datastore migrations, generally the guarantee is compatibility with the previous version of SpiceDB -- there are cases where it's more complicated and takes multiple phases of deployment to roll out the migration with zero downtime, but those are documented in the release notes (e.g. v1.14.0).
If you're running on Kubernetes, the SpiceDB Operator just does all of this for you with zero downtime every time.