1. Have the code recognize the new value. Get that shipped everywhere.
2. Have the code do something reasonable when the new value appears. Get that shipped everywhere.
3. Start emitting the new value.
My proposal is
1. Have the code recognize the new value. Have the code do something reasonable when the new value appears. Get that shipped everywhere.
2. Start emitting the new value.
If the user has to manually update, and might refuse to do so, the problem exists under both the 3 step and the 2 step process. So nothing is gained by using the 3 step process.
If the client and backend are updated independently, that should still be fine with the 2 step process. The 2 step process says "Get that shipped everywhere", meaning shipped to both the client and the backend.
1. Support the new value in your schema
2. Support the new value in the client
3. Emit the new value from the server
Combining 1 and 2 is probably possible, but not a great idea. Imagine if you end up rolling back 2 and 3, but there are still potentially new values in flight. If 1 is still there, you're good. If 1 and 2 are combined, you rollback all 3, but the new value is still in flight and your client crashes.