-
Notifications
You must be signed in to change notification settings - Fork 7
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
Use BE:PORT/Service/version endpoint rather than GetBackendInfo to get BE's version #250
Comments
@billmeek I think we need to figure out how/where we are going to use this information. Aside from tests in the troubleshooter, it could really be used to differentiate functionality based on the backend you are connecting to. Is there anywhere that breaks down the individual API versions with the methods/signatures of the implemented endpoints? Where would we present this info in the app. I was thinking we could see if we could use the bottom portion of the navigation drawer. Maybe even get rid of the About dialog and move most of that down there too (if its possible) |
@billmeek would it be possible to refactor I would recommend adding a ServiceInfo object to the BackendInfo object so that it would match something similar to the following:
I am also thinking it would be helpful for Build object to contain a normalized version of mythtv. So it would just contain 0.27, 0.28, 0.29, etc. Whichever is appropriate for the version of the backend running. Thoughts? |
Great ideas. I'm looking into the GetBackendInfo one. No joy yet. If possible, I think I'd add a parameter, e.g. GetServiceVersions to It wouldn't be necessary to call eachService/version all the time, just The normalized version one looks tougher, not that it couldn't be Interesting that I've gotten no replies on G+ from app users that |
Looks like Arch uses atypical versions: |
As discussed in #246, some distributions and or users aren't using the
'normal' MythTV version string e.g. v29-pre-303-g37c172e-dirty. This
makes the existing tests unreliable.
Considering that there is no known evidence of users changing the
Service/version endpoint's value, it seems to be a more reliable way
to be sure the app will be compatible with the Services API.
Example:
The text was updated successfully, but these errors were encountered: