How to warn about the outdated version of the internal utility

Imagine this situation:

• We have an internal utility (say, a level editor). From time to time there are new versions.
• Information is stored in XML or other tree extensible format. At the same time, we, like the bright Jedi, are monitoring compatibility from the bottom up, and later versions open all the earlier projects.
• The tool is used by non-technical people and not affected by the “early imitator syndrome”. They do not need to have the latest version of the editor; the main thing is stable and the same in a single project.
• From time to time new functions appear, new blocks appear in XML for these functions. At the same time, such a situation is possible: let two work on one project. One program supports new blocks, the other does not. The second, having saved 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, most likely, “will take the roof off”, and it should warn before loading: “This is a save game from the new version and, most likely, incompatible. Do you want to continue downloading? ”
• Similar confirmations are needed if we open the old version with a new version. The utility is still internal, and you shouldn’t preserve the support of old saves for recording in it.
• Since the utility is internal, it is on the rights of “it's beta than nothing”, and our professionalism is the only guarantor of its bezglyuchnosti. Sometimes there are “black” versions that spoil the data. How to warn the designer that a nasty mistake has crept into his version?
• Need to do without a centralized update server.

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

In each document we store four fields.

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

At the same time, BuildSaved> = BuildSupported> = BuildRequired. Version numbers I asked hard in the source. A new field has appeared in XML - replace BuildSupported with the current version. Perekroil storage format - replace immediately BuildSupported and BuildRequired. BlackBuilds defined speculatively, according to changers - from the version in which the erroneous functionality appeared, to the one in which they noticed and corrected.
')
Opening the 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, incompatible. Do you want to continue downloading? ”
• If the version is lower than BuildSupported, we inform you: “There may be new fields in the document, which will be lost during re-saving”.
• If the version is one of the BlackBuilds, we inform you: “Your version spoils the documents. Save nothing, upgrade to a less dangerous version. ”
• If BuildSaved is one of the “black” versions stored in the EXE file, we conclude: “The document has been saved with a dangerous version. There may be errors in the document. Let the one who saved the document be immediately updated. ”
• Finally, if an outdated data storage mechanism is found, we conclude: “Before backing up, make a backup copy”. And even better, make a backup automatically (suggested by jhe ). There are already no naked statements based on a single figure. BuildRequired: when we download, we see for ourselves the outdated format or not.