-
Notifications
You must be signed in to change notification settings - Fork 70
Error if unsupported version in toltecctl #576
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
Conversation
This is currently untested |
Did some spot testing on my rM1 and the code seems sound. I haven't tested by updating to the latest OS though. |
This will need to be updated when #579 is merged. |
Just tested and this seems to work properly. The values are for the latest stable as we'll be adding support for it with the other changes on their way into testing. |
Thanks for your work on this, Eeems! Haven’t tested this yet but judging by the diff this looks good. Only thing is, I’m not sure hardcoding the supported version numbers in the script itself is a viable solution. Consider the following situation: someone upgrades to the latest OS release while Toltec doesn’t yet support it, so What about instead publishing two files on our website that would contain the latest supported version numbers? The script could pull those files and compare their value against the current Also, I’m not sure I understand the rationale for running |
Technically they would still be able to install by using --force on the reenable. Fair point though, we should check something to see if the supported version has changed. How do you want to keep track of that? I've seen some people running switch branch without understanding what it actually does already. We probably should include a version check there still, but only if we have the supported version be per branch. That way we can keep people from switching back to stable on a version that isn't supported in stable yet. |
The solution I have in mind is to publish a file on our website containing compatibility information. For example, we could add a file named
The version field would be used for displaying information to the user on the latest supported version, and the timestamp field would be used for comparison with the
Sounds good. Should we also call the check function in the |
Seems reasonable. We will have to split this information between rM1 and rM2 somehow. Do you want me to update the PR to handle this?
I think it would be a good idea to do so. |
Added a quick implementation of what we discussed above. Untested for now. |
Did you ever get a chance to test this? |
@matteodelabre poke |
#616 is a reminder that this needs to be finalized. I probably won’t have enough time for this until the start of next month. |
@matteodelabre poke |
#731 we probably should focus on this again soon. |
Unfortunatly using /etc/version as an always increasing value will no longer work, one of the 3.6 releases has a value from 2018. We can pull the official value from |
I've updated the logic to handle minimum and maximum versions, this should provide the building blocks required to start generating multiple repos with different OS version ranges. I haven't tested anything yet, but in theory it should work. I also fixed up the version compare logic to use |
Closing in favour of #759 |
Fix #445