3 ms·
> configuration mechanism should be considered to be part of the public interface, which requires managing backwards compatibility when changes become necessary
by jraph 3y ago
> configuration mechanism should be considered to be part of the public interface, which requires managing backwards compatibility when changes become necessary
I'm not sure it's quite related to the fact you shouldn't have to maintain a fork of the configuration, but absolutely agree.
As it happens, I deprecated three configuration parameters in a project I work on just yesterday this way [1]. It is enforced by the fact the configuration is defined using a Java class checked by revapi. I just deprecated the related methods, hidden the properties (so they don't appear in UIs), made the setters do nothing and the getters return the most sensible values given the new behavior.
[1] https://github.com/xwiki-contrib/confluence/commit/fad5d0c52601008a760f41babd4ba6221c6e357e#diff-afd15c0e7fc621734649298674a3174d9c9554d0be04ce0785d83c794a1504fe https://github.com/xwiki-contrib/confluence/commit/fad5d0c52...
- samus 3y agoThe problem still applies even when the user only sees a UI, but in a less explicit way. Power users usually customize a lot of settings that they expect to still find in updated versions. If there is no sane way to export those settings*, then people will remember it or write it down somewhere. *: looking at you, Putty, which stores connection settings in the Windows registry
- jraph 3y agoYep, that's something Firefox manages the right way I think (in about:config). Each setting can be in different state: - default value - explicitly set to something As such, parameters set to the default can (and should) be changed in further upgrades, explicitly changed values should be kept, unless they don't make sense anymore.