Settings and files migration

[zeule]

With profiles and portable mode in place, settings and files migrations have to be performed per-profile. We have two migration suggestions already: migrate settings files into configs location (Windows) and migrate data to ~/.local/share (UNIX). And this would be better to decide before 3.4.0 release, when profiles go into wild life.

My suggestion (looked up in Kile (KDE LaTeX editor) is: let's always write qBt version into the config file and then use this version as an indicator which uprgrate/migration steps are needed. In the app we can collect a dictionary of version->upgradeFunction opbjects. then comparing version from the settings file to the versions in this dictionary, we select required steps, sort them by version and run.

[glassez]

@evsh, do you want to support bidirectional migrations?

[glassez]

migrate settings files into configs location (Windows)

Apparently, the currently used config location is correct. As I said in another issue:

As I understand it, AppData/Roaming is for the data/settings that can be moved between different computers in a domain, and AppData/Local is for computer specific data/settings. So current behavior is correct (maybe, except some particular settings).

[zeule]

@evsh, do you want to support bidirectional migrations?

No, I don't. Does anybody want to write twice more migrating functions?

Apparently, the currently used config location is correct.

OK, I missed that somehow. Then only one possible migration is under consideration.

[glassez]

No, I don't. Does anybody want to write twice more migrating functions?

+1
I don't think it is implementable at all.

And this would be better to decide before 3.4.0 release, when profiles go into wild life.

+1

[sledgehammer999]

This is the first time I saw this.
I am bit confused what the problem is here that you're trying to solve. Are you talking about the upgrade/migrate code already in place or you talking about somehow migrating configs and data files elsewhere?

If the 2nd part why is it needed to do that?

[zeule]

We were discussing config migration from version to version and that migration functions are scattered all across the program, and that migration should be somehow controlled by Profile objects.