Improve config upgrade experience about xplr HOT 10 CLOSED

I think incremental config update is the way to go. "Only add the part of config you want to change".

from xplr.

I couldn't step into the brainstorm but current state of the config file also seems fine to me.

@maximbaz done!

from xplr.

Now that we have incremental config, and we concluded that it's beneficial to keep the config versioned (at least for now), and we have src/config.yml with an example of full config with all the default values (@orhun could you pls make the package install this to /usr/share/xplr/examples/config.yml?), I think all my points got covered 🙂 Really nice job! Should we close this?

from xplr.

Hey thanks for your inputs. I really wanted to get feedback from someone and brainstorm just like this.

As for the config file, I wouldn't want any app to update files in my config dir. Also, I don't think we should make it app version independent. Because that will complicate things. I'd prefer that users, just by looking at the version should be able to tell whether it's compatible or not.

Also, there are 2 kinds of change, one is non-breaking feature addition, where for e.g. new messages are added without deprecating any other message. I want to find the least annoying way to inform users of such changes. For now, users will see an info level log for each change, which I agree isn't optimal. But the users can always ignore that and update the config without visiting the guide and that's ok.

And then there are the breaking changes, where some messages are deprecated or replaced. So they'll have to update their config file following the guide.

And I'd also want to avoid making installation platform/packaging dependent.

I like the in-repo config file idea and I think we can explore more in this line.

The offline guide is also a great idea, but that has a drawback. I won't be able to change the docs once I ship a new version, so I'll have to be extremely careful and account for all possible scenarios when writing the upgrade guide. So maybe in the future when the project is a bit stable, it'll be a good option.

from xplr.

Updated the information in wiki: https://github.com/sayanarijit/xplr/wiki/Upgrade-Guide
Config file: https://github.com/sayanarijit/xplr/blob/main/src/config.yml

from xplr.

While we are brainstorming, here's another idea: what if users would only put in the config file what's different, not the entire config? And then xplr merges that small diff with the default config. And in that case maybe the versioning is not even needed, if I only have things in my config that I wanted to change? Either they still work, or they no longer work (as in case of breaking change).

from xplr.

I think this is how most other tools work. At first, I had doubts if this was possible at all with xplr, since xplr works more like a framework than a tool, exposing a bunch of messages and pipes, leaving it upto us how we use them. But now after some thinking I think it's possible to an extent. Though, I would still prefer xplr to fail and break than running outdated configs and behaving unexpectedly. Hence, I'm still reluctant to remove the version.

from xplr.

Another way probably is to have a strong plugin system so that users don't have to use the messages themselves. Users can just install plugins, and it'll be up to the plugin authors to maintain compatibility. The plugin system should provide necessary validation against version incompatibilities.

from xplr.

That said, I'll be stabilizing the messges and the api soon. So in the near future, there will be less breaking changes to look out for.

from xplr.

Sure... Thanks all your valuable suggestions.

from xplr.