When we release a new version, any changes to the models (additions or modifications of fields or concepts and their connections) have to come with an accompanying set of instructions for how to migrate data in the old schema to data in the new schema. As the developers, this means that we may need to provide custom migration scripts that ensure that every user has their data moved into the new system in a consistent way that avoids conflicts. This is going to be tricky, and means that after our first release changes must be very important and deliberate. Additions aren't as hard, since they don't affect existing values, but anything that modifies existing data must be done thoughtfully.
A description of this process, and any special instructions for upgrading a server from version X to version X+1, should be kept in a clear document.
mwhall
commented
5 years ago
When we release a new version, any changes to the models (additions or modifications of fields or concepts and their connections) have to come with an accompanying set of instructions for how to migrate data in the old schema to data in the new schema. As the developers, this means that we may need to provide custom migration scripts that ensure that every user has their data moved into the new system in a consistent way that avoids conflicts. This is going to be tricky, and means that after our first release changes must be very important and deliberate. Additions aren't as hard, since they don't affect existing values, but anything that modifies existing data must be done thoughtfully.
A description of this process, and any special instructions for upgrading a server from version X to version X+1, should be kept in a clear document.