|
|
|
|
|
|
by lukejduncan
3388 days ago
|
|
|
I don't know if this helps, but reading up on backwards and forwards compatibility can get you in the right direction. The same concepts apply, but the details may very. For API interfaces read up on or think through best practices around overloading old fields, adding new fields, removing old fields, making them optional. I remember Acro had a "schema evolution" doc that talks through some of these concepts and they may apply to things you care about. For databases, I've seen updates staged as pre-commit, post-commit, and rollback patchs. Pre-commit modifies the database in a backwards compatible way -- for example adding new fields and mutating old fields into them if necessary. Code would be pushed live and could read the "old" or "new" way. After all the code is rolled out and there's high confidence the post commit would cleanup things left behind only for backwards conpatabaility reasons. Rollback only operated on pre-commit, post commit may be destructive. |
|
|