Depends on your updating architecture.. If you have a central backend service, but scheduled patches or the user has to manually update, that might become a problem. There could also be the case that client and backend can be updated independently and one might not be done before the other. The issue might only exist for a few minutes, or an hour, but would still be a huge impact on the software.
Sorry, I still don't understand. The post say you need to do
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.
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.
The advice seemed to be to, first, support (i.e. correctly ignore) any possibly new value in both the client and server (i.e. any client of the 'schema').
If 2. breaks when you do 3., you roll back to 1. If you rolled back to the one before 1, then the values that 3 emitted may still be in the system, causing it to break. When you do 3, you're really testing 2 and 1 is the fallback. If you did 1 and 2 together, then you can't roll back just 2 on its own.
