Closed bsoule closed 1 year ago
The app treats this parameter as required / non optional. A(n ugly) force unwrap is used to extract the panic value from the json. Should this be missing, the app will crash.
Since the api is as good as not versioned and the app is as well, the nice way to transition would be to continue exposing it in the api while releasing app versions that handle its absence gracefully. Once enough clients have updated, remove the parameter from the exposed json/api.
I think we can increment a number on the backend and the iOS app will gracefully show an "Update required" dialog rather than just die, right?
Is this change pushed out to the public? If so, do we know about what percentage of folks are already on it?
It's not yet in a publicly released version - it will go out with 6.1 (see attached milestone).
I'm not aware of any analytics in the app in terms of reporting version usage (I had assumed this was due to a philosophical dislike of tracking people). There is support for a server-configured minimum supported app version. It it would help we could have the app include a version number as a the header for its existing API requests, and then the server could report on this using any existing metrics solution it has.
This change went out with 6.1 which was released 2022-10-04, and all users were eligible for auto-update as of 2022-10-11. So it's probably ok to update the minimum supported version (set by the server) to 6.1 some time in the coming week, and then remove panic
a week or so later.
There is a long deprecated parameter in the beeminder api output (one of many, yes), called
panic
that is going away.Full disclosure: I actually removed it from the api output today as it's been gone from docs and the goal settings interface for years, and removing it borked the iOS app. So I put it back, and there's the deprecation warning: we want it to go away. What do we need to coordinate with the iOS app to make that happen?