Auto-Migration

[Volte6]

Description

This defines a basic process for including auto-correcting/updating of datafiles etc. when users upgrade to a new binary version.

Changes

• main.go now defines VERSION - this should match release versions
• internal/migration/ code foor migration purposes.
• migration code is invoked in main.go before datafiles etc. are loaded (except for config)
• fixes a small error in training room script
• migration creates a backup of datafiles and restores on any errors
• flag --version can be used when running gomud to display version and quit
• version set to 0.9.1

[MorquinDevlar]

I think is a good idea, although I don't see any kind of backup being taken before migration is done. If migration fails, there is seemingly no way to get back to the previous version.

Also, I don't see any validation for loading zone config's, and potentially adding missing ones before migration. Just an observation.

[MorquinDevlar]

Wouldn't this consider equal versions as older than each other? I would think this should be just < Older

[Volte6]

This < in this case is technically doing a comparison vs. a constant taht's returned. It should really be =.

Fixed.

[Volte6]

I think is a good idea, although I don't see any kind of backup being taken before migration is done. If migration fails, there is seemingly no way to get back to the previous version.

Also, I don't see any validation for loading zone config's, and potentially adding missing ones before migration. Just an observation.

A full backup would probably be a decent idea, and then a revert on failure... I'll implement something simple for that.

I'll add some logic to check for a zone-config as well. If it already exists, we can probably ignore the migration for that file... it's should be harmless to leave it in there.