Execute system commands via hotkeys or command palette in Obsidian (https://obsidian.md). Some automated events are also supported, and execution via URI links.
GNU General Public License v3.0
351
stars
11
forks
source link
Internal: Store plugin version in the settings file #90
Some version upgrades need to alter the data.json settings file's structure to introduce new settings, or to improve how the settings structure works. For that, the plugin has migration functions in place to convert old settings structures to new structures when a user upgrades the plugin. So far the migrations have been made to run if new field names are not present in the settings file, or if old field names are present.
Old migrations need to be removed from time to time
1.0.0 will remove some migration functions in order to clean up codebase a bit. I'd like to create a warning system that if a user happens to have a too old settings file for 1.0.0 to understand, the plugin would display an alert and suggest the user to first downgrade to the newest version in 0.x.y line in order to get their settings file migrated to a format that is understandable by 1.0.0. Users should not face this situation often.
Settings version number
For this warning system, I'm going to write a settings version number to the data.json settings file. It won't be visible to the user in normal circumstances. The settings version number is the plugin's version number, but with the exception that settings version number is not increased if a new plugin version does not introduce any additions or changes to the settings structure. The first settings version number will be 0.7.0, as that version will introduce changes to the settings structure.
When this kind of version number can be found from the settings file, it will be easier for the plugin to check if it still can support that settings file or not. I try to keep migration functions on board for a long period of time so that users do have time to upgrade their plugin to the last 0.x.y version that makes settings changes before hopping into version 1.0.0.
Noticing if a settings file is too new
Another small (and rare) problem that will be solved by this feature, is that the plugin can then recognise if the settings file format is too new for the plugin. That can happen if a user has the same vault on multiple machines and plugin settings are somehow synchronised, but one machine happens to have a newer version of SC than another machine. Then SC can alert the user that "This settings file format is too new for me, please upgrade SC so that I'll learn how to read the settings file."
Taitava
commented
2 years ago
Background
Some version upgrades need to alter the data.json settings file's structure to introduce new settings, or to improve how the settings structure works. For that, the plugin has migration functions in place to convert old settings structures to new structures when a user upgrades the plugin. So far the migrations have been made to run if new field names are not present in the settings file, or if old field names are present.
Old migrations need to be removed from time to time
1.0.0will remove some migration functions in order to clean up codebase a bit. I'd like to create a warning system that if a user happens to have a too old settings file for1.0.0to understand, the plugin would display an alert and suggest the user to first downgrade to the newest version in0.x.yline in order to get their settings file migrated to a format that is understandable by1.0.0. Users should not face this situation often.Settings version number
For this warning system, I'm going to write a settings version number to the data.json settings file. It won't be visible to the user in normal circumstances. The settings version number is the plugin's version number, but with the exception that settings version number is not increased if a new plugin version does not introduce any additions or changes to the settings structure. The first settings version number will be
0.7.0, as that version will introduce changes to the settings structure.When this kind of version number can be found from the settings file, it will be easier for the plugin to check if it still can support that settings file or not. I try to keep migration functions on board for a long period of time so that users do have time to upgrade their plugin to the last
0.x.yversion that makes settings changes before hopping into version1.0.0.Noticing if a settings file is too new
Another small (and rare) problem that will be solved by this feature, is that the plugin can then recognise if the settings file format is too new for the plugin. That can happen if a user has the same vault on multiple machines and plugin settings are somehow synchronised, but one machine happens to have a newer version of SC than another machine. Then SC can alert the user that "This settings file format is too new for me, please upgrade SC so that I'll learn how to read the settings file."