New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto-updates + Config Migration #122
Comments
I have been thinking about this a bit. Forcing a new schema sucks, but it might be (eventually) worthwhile. If the config were to codify a schema version in it we could make converting over less painful. So our example config.fnl, when we have a new schema, introduce a core could detect old schemas and warn users that they are using a deprecated schema, and if someone were brave they could write something like "Compatible" schema changes could just be new features added as new keys that don't break a config, but the user loses out on the new feature. We can still warn in these cases and offer the transformation. Incompatible changes would be things like removing or moving keys. We could use something like semver to differentiate the two. |
An interesting problem, @agzam mentioned, that rears its head again when implementing fixes like #121, is we don't have a great way of communicating new potential settings and their defaults to existing users.
The current system favors stability and our goal as maintainers is to only introduce additional config, but it also means existing users may not know about these new options like being able to set a ratio for how to center windows on the screen.
I'm thinking we could create a migrate.fnl script that users can run after updates that will communicate new default settings.
Basically it be a list of objects that check for the presence of a new setting, inform the user what it's used for, and gives them the option of adding it to their config or not.
Usage example:
The other feature @agzam expressed interest in was some kind of auto-update functionality. He mentioned leveraging homebrew for this. I'm not quite sure I understand how that would work but I'd like to hear more!
Alternatively we know spacehammer users are likely to have at least git and hammerspoon installed. Maybe we could have it check either on startup or once every week for spacehammer releases (or latest commit-sha) and if it has changed, display a UI for users to automatically run the git commands
git pull https://github.com/agzam/spacehammer.git master --rebase
and perhaps iterate through the migrations list from migrate.fnl and walk the user through updates.A potential enhancement to that would be remembering what users select for each migration so if they skip it, we don't prompt them again. But that's more of an edge-case not really a release blocker.
The text was updated successfully, but these errors were encountered: