4 ms·

The bottom line seems to be that such ad-hoc configuration mechanism should be considered to be part of the public interface, which requires managing backwards

by samus 3y ago

The bottom line seems to be that such ad-hoc configuration mechanism should be considered to be part of the public interface, which requires managing backwards compatibility when changes become necessary. Developers usually don't like doing that and are probably only used to do this with function signatures and object structures, not with source code files. Under that lens, it should become obvious how bizarre it is to expect configuration to happen that way. What could an alternative be? First of all, considering user-friendly configuration as a first-class feature and explicitly thinking about the upgrade path. Developing a configuration file format and most importantly having a backwards compatibility policy for that seems the obvious solution.

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 ago
  The 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 ago
    Yep, 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.

by samus 3y ago

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 ago
The 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 ago
  Yep, 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.