RPTools
[Feature]: Before migrating a *.cmpgn file to the latest MapTool, create a backup to protect users from data loss -- and themselves.
Feature Request
MapTool development has been doing a great job of providing backward compatibility with earlier MapTool versions and downward compatibility for those wanting or needing to go back to an earlier MapTool version.
Downward compatibility isn't perfect, though. I will not spend the time to file an issue on this, but I had a campaign in MapTool 1.11.x that was NOT compatible with going back to MapTool 1.10.4. I had to redo it.
In summary, users should be protected (reasonably) from these types of issues. It's a good practice to ALWAYS backup your *.cmpgn file before loading and saving it in a new MapTool version. Therefore, I recommend that this process be automatic and optional.
I propose that before saving a *.cmpgn file in the new MapTool version that part of the dialog has a checkbox (checked by default) to preserve a backup of the original *.cmpgn file under a name of the format:
where "maptool-x.x.x" is something like "maptool-1.8.3", if that was the last version used to save the file.
A complete example might be something like "Hill Giant Fortress.maptool-1.8.3.backup.cmpgn".
The save dialog should have a checkbox (checked by default) to create this backup -- and all new installs should always start with this checkbox checked.
It can also fill another role to preserve a backup of the file on disk before overwriting it with the newly saved file by simply creating a file using the current MapTool version. Assuming it's MapTool 1.12.2, then the file would look like the following using the above example:
"Hill Giant Fortress.maptool-1.12.2.backup.cmpgn"
Doing all this provides the following:
-
Prevents even experienced users from backing up their *.cmpgn file, if they are normally inclined to do so.
-
More importantly, it enables MapTool development to be more bold in deprecating features that no longer seem to be needed or are getting in the way of future development. Stress that users should always retain a backup of their *.cmpgn files when upgrading to a new MapTool version and retain those backups till they know their sure. Recommend always keeping these backups as an opportunity to go back should the worst happen.
The Solution you'd like
- When saving, MapTool's save dialog includes a checkbox (checked by default) to save the previous file under a name of the folllowing format:
-
This checkbox should always be checked when a new MapTool version is installed.
-
If the user unchecks the checkbox during the course of using new MapTool install, then persist that decision to leave it unchecked going forward (until the next new install).
-
I believe a simple rename can be done on the old file, if it still exists. If it doesn't, display a warning dialog and give the user the option of continuing without doing the backup.
Alternatives that you've considered.
Losing data should be prevented at every opportunity. It's really the first job of an application not to lose data -- and to help prevent users from inadvertently losing their data.
I don't recommend depending on users to use the features of their OS to make their own backups. Instead, facilitate the process to help those that want to do it.
Additional Context
I believe that MapTool development needs to consider a development model of informing the user community, deprecating features that no longer seem to make sense carrying forward, and, then, removing those from MapTool releases. Making it easy for people to go back to earlier MapTool versions that work better for them is a way to smooth this over -- especially if they didn't know the feature was removed in a later version and you didn't know it was still important.
For example, I might be one of the only ones using the Hero Lab integration feature. It would kill my PF1e framework (game system) to lose that feature.
One way to deal with it is, sorry dude but we've decided not to carry that feature forward because we don't think that many people are using it -- but you can continue to use MapTool 1.10.4, for example, as long as you like. You just won't get the new features.
A better way to deal with this would be to give me an upgrade feature that might require me to do a little bit of work but is well worth it in the end such as XML parsing capability to replace the proprietary nature of the Hero Lab interface (which currently uses XML but only works with Hero Lab). Then, I could start a project to switch it over to generic XML parsing and decouple from the Hero Lab interface (which provides XML that could be saved to files). In this case, an older feature would be completely replaced with a newer, better and more generic feature. In this case, the older feature, especially if almost no one is using it, should be dropped and not carried forward.
An alternative is to do the backup when loading the campaign instead of when saving it. Show the user a dialog like "This campaign was saved in an earlier version of MapTool. Would you like a backup created? / Yes / No" + some option not to be asked again. Or we can even do the backup implicitly, putting the backup in user's maptool directory where it can be found if needed, but otherwise stays out of the way.
@bubblobill just bumped this in Discord...
This would actually be pretty easy to implement. The current campaign save process involves creating a new (empty) zip file, writing everything to it, then renaming the existing campaign to a tmp name, moving the new campaign to the original name, then deleting the tmp file.
This is done so that if anything fails part way through, the original campaign file is recoverable. However, the last step of removing the tmp file could be changed so it is renamed instead.
