For some reason the version number isn't working as expected. Need to figure out how that works and get it working correctly.
I'm thinking of using the dnscrypt-proxy version to keep the config in lockstep with the application.
It just so happens that the version of dnscrypt-proxy has 3 segments, the same as what is supported in the config nodes.
I'm contemplating including the plugin revision number as a suffix to the version number (e.g. 2.0.45-1), however, the config model is unlikely to change much between versions.
I think it may be reasonable to include it in the case of a model structure change due to new features being developed and implemented within a release. This would allow flexibility and a migration path for existing settings even within the same version of dnscrypt-proxy.
Something also to consider would be the case where the dnscrypt-proxy version number changes, but the settings don't (bug fixes, etc).
For some reason the version number isn't working as expected. Need to figure out how that works and get it working correctly.
I'm thinking of using the dnscrypt-proxy version to keep the config in lockstep with the application.
It just so happens that the version of dnscrypt-proxy has 3 segments, the same as what is supported in the config nodes.
I'm contemplating including the plugin revision number as a suffix to the version number (e.g. 2.0.45-1), however, the config model is unlikely to change much between versions.
I think it may be reasonable to include it in the case of a model structure change due to new features being developed and implemented within a release. This would allow flexibility and a migration path for existing settings even within the same version of dnscrypt-proxy.
Something also to consider would be the case where the dnscrypt-proxy version number changes, but the settings don't (bug fixes, etc).