How to warn about an outdated version of an internal utility

Imagine this situation:

• We have an internal utility (say, a level editor). New versions are released from time to time.
• Information is stored in XML or another tree-like extensible format. At the same time, we, as light Jedi, monitor compatibility from the bottom up, and later versions open all early projects.
• The utility is used by people who are not technical and are not subject to the “early imitate syndrome”. They do not have to have the latest version of the editor; the main thing is stable and the same within the framework of one project.
• New functions appear from time to time, new blocks appear in the XML for these functions. At the same time, this situation is possible: let two people work on one project. One program supports new blocks, while the other does not. The second, saving the project, will simply lose these blocks.
• Sometimes you have to “redraw” the data storage format. For example, there used to be one tileset - now a whole bunch. The old version is likely to “blow the roof”, and before downloading it should warn: “This is a save from the new version and, most likely, incompatible. Continue downloading? ”
• Similar confirmations are needed if we open an old project with a new version. The utility is still internal, and you should not preserve the support of old saves for recording in it.
• Since the utility is internal, it has the rights of “it's beta than nothing,” and the only guarantee of its lack of integrity is our professionalism. Sometimes “black” versions appear that spoil the data. How to warn the designer that a nasty mistake has crept into his version?
• You need to do without a centralized update server.

I came up with this simple solution in 2005, working on mobile games, in order to somehow cope with the zoo versions.

We store four fields in each document.

• BuildSaved - the version that we saved the project.
• BuildSupported - the smallest version that is guaranteed to fully open this save game.
• BuildRequired - the smallest version, which at least partially, but without errors, will open this save game.
• BlackBuilds - all versions that corrupt data.

At the same time, BuildSaved> = BuildSupported> = BuildRequired. I set the version numbers hard, in the source. A new field has appeared in XML - replace BuildSupported with the current version. Redid the storage format - replace BuildSupported and BuildRequired immediately. BlackBuilds determined speculatively, by changelogs - from the version in which the erroneous functionality appeared, to the one in which they noticed and corrected.

Opening a document, we do such checks.

• If the current version of the program is lower than BuildRequired, we inform: “This is a document from the new version and, most likely, is incompatible. Continue downloading? ”
• If the version is lower than BuildSupported, we inform: "The document may have new fields that will be lost when re-saving."
• If the version is one of BlackBuilds, we inform: “Your version spoils the documents. Do not save anything, upgrade to a less dangerous version. "
• If BuildSaved is one of the “black” versions stored in the EXE file, we output: “The document was saved by a dangerous version. There may be errors in the document. Let the one who saved the document be updated immediately. ”
• Finally, if an outdated data storage mechanism is detected, we output: “Before you re-save, make a backup copy.” Better yet, make a backup automatically (suggested by jay ). There are already no bare statements based on one BuildRequired digit: we see when loading ourselves whether the format is outdated or not.