No versioning for settings
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Xpad |
Confirmed
|
Medium
|
Siergiej Riaguzow |
Bug Description
~/.config/
This means that if preferences change:
- user might not even find out about the change
- if they change drastically leading to incompatibility with the old one, there may be bugs
I will not add versioning as part of resolving of https:/
This integer should be bumped in very rare cases (when indeed something is changed in settings) so that not to confuse user with removing his customizations all the time
Changed in xpad: | |
assignee: | nobody → Siergiej Riaguzow (riaguzov) |
Changed in xpad: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
I agree with your findings and reasoning.
Thinking about how to implement this, this idea crossed my mind.
We have to implement: color_default) and to remove obsolete/deprecated items.
- a configuration versioning schema numberering: to keep it simple, we could use the Xpad version number.
- a lookup table which elements in the configuration file correspond with which version of Xpad. This gives us the possibility to upgrade the configuration file by adding new items (for example first_pad_
- a automatic validation and upgrade/downgrade of the configuration file up-triggered on Xpad application startup.
I bet there is existing code for this which we can use as a base.