versioning MPIPreferences metadata

[simonbyrne]

We should probably add some mechanism to version the MPIPreferences metadata. The obvious way is to add a version and/or format key (similar to those in the Manifest.toml).

@giordano @vchuravy any suggestions on how best to do this?

[giordano]

That's a good idea, but I'm not sure how to best do that. A prefs_version key is too naive? @staticfloat any thoughts on versioning preferences?

[staticfloat]

I assume this is to allow storing separate preferences for different versions of MPIPreferences? I would just store all of your preferences inside of a dictionary that is keyed by the package's version number; or maybe keyed by the major and minor parts, so patch releases all share the same settings.

[simonbyrne]

I assume this is to allow storing separate preferences for different versions of MPIPreferences? I would just store all of your preferences inside of a dictionary that is keyed by the package's version number; or maybe keyed by the major and minor parts, so patch releases all share the same settings.

No, that wasn't my intention. It was more trying to think about compatibility: if we need to change what we store (add more additional keys, change the values certain keys accept), what would be the best way to do this?

If the preferences are stored in a given project, then this is simply determined by the compat restrictions on MPIPreferences.jl, and so it isn't really a problem. But since we allow preferences to be inherited from the environment stack, we could end up with the case where the preferences which are loaded are from an older or newer version of MPIPreferences than that used in the current project.

My current idea was to add a _format key, which would have a similar role to the manifest_format key in the Manifest.toml. Is this the sort of thing that could be a standard convention?

[vchuravy]

I like the idea of a format key. We don't want to version the settings but we want to warn if someone loads settings that are incompatible.