You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 5, 2024. It is now read-only.
As we saw in the recent issues caused by renaming the project, I propose that there should be same way of upgrading versions. Here are some solutions which may or may not be interchangeable:
Store the latest version or commit hash in the config files. (this should be done anyhow) - though maybe a config specific version would be better so it could be known when it changes.
Add to the upgrading steps to README (this akes it slightly harder if updates become automated e g through an AUR package)
There is already a version set in setup.py, that can be changed in the code. Everytime that someone calls onedrive-client --version will get it.
I'm a little bit sceptic of having an automated tool to do the migration. I like the idea, but I think there will be a lot of development involved, and also we would have to support different versions and so on. I don't think these "break changes" are so frequent, so I would rather use pip install --upgrade onedrive-client instead...
I am meaning to store the version in the config - separately to the actual runner version. Maybe a better solution is to add an issue template and when adding issues require the config to be removed and recreated as a way of debugging (and hence the version would allow us to tell if any major changes).
I think I'm not following... What config is this? Why the config and the runner can have a different version? And can you say an example for a issue that requires removing and recreating the config?
Sorry for the late reply. What I'm trying to say is in the config (~/.config/onedrive_client) we store the application version at the time the config was created and request that when someone files an issue; as well as the onedrive-client --version (of which doesn' work for me).
Thinking about it, this seems to have little point. Closing anyway.
As we saw in the recent issues caused by renaming the project, I propose that there should be same way of upgrading versions. Here are some solutions which may or may not be interchangeable:
Store the latest version or commit hash in the config files. (this should be done anyhow) - though maybe a config specific version would be better so it could be known when it changes.
Add to the upgrading steps to README (this akes it slightly harder if updates become automated e g through an AUR package)
If the config specific version changes:
a. Every run, until something is done (in which case the version indicator is changed), ask/recommend that the user delete and recreate the config - this runs into problems because of Unable to compare existing files downloaded via other methods. As result, onedriveClient is downloading/uploading everything again #22 and Systemd Service #20 (the latter as the message would not be seen)
b. Use input() inside of setup.py (is this bad practice?)
Create some sort of automated tool that can migrate between versions (harder but solves all the problems)
The text was updated successfully, but these errors were encountered: