This message was deleted.

The schema version exists so we can migrate from whatever you have to "current", whatever that means for the running application.

@proud-jewelry-46860 Does this mean I'm going about it the right way and won't need to think about the schema version later on or? 🙂 Thanks for the quick reply btw.

the intent of the schema is that it is backwards compatible. so a future scheme might include elements for a new feature in the product so you may need to revisit it again, but the goal would likely be that for features covered by a schema level it wouldn't need rework.

The migrations for the locked schema is intentionally conservative. If a new feature is added, that an organization may reasonably want to lock down, then the migration will automatically lock the feature as disabled, even if the profile doesn't include it (because it didn't exist in earlier versions). An example is the Wasm support added in schema version 11. If you are migrating a locked profile from version 10 or earlier, Wasm will be disabled and locked: https://github.com/rancher-sandbox/rancher-desktop/blob/f910855c23329ac412ebe96c77fbafecfd00739e/pkg/rancher-desktop/config/settingsImpl.ts#L476-L481 If you have a schema 11 or later profile, and don't mention Wasm, then it will be unlocked, because you have the setting available in your schema, but choose not to lock it.