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
Currently the app works with any Zulip Server version 4.x or newer. This is documented in our README and reflects what's documented at https://zulip.readthedocs.io/en/latest/overview/release-lifecycle.html . With #267, we'll start giving an explicit error if the user tries to connect to an older server.
At some point we'll want to increase that minimum to 5.x. As recorded at https://blog.zulip.com/tag/major-releases/ , 4.0 was released in 2021-05, over 2 years ago, and 5.0 in 2022-03, approaching 1.5 years ago.
When we do, we can follow up by sweeping the codebase for TODO(server-5) comments and acting on all of those. That will be in the same spirit as zulip/zulip-mobile#5100 and zulip/zulip-mobile#5192 in the old zulip-mobile RN app. (And zulip/zulip-mobile#5708, though that's a draft that was made moot by our migration to Flutter.)
There is one spot where we already don't fully support older than server 5.x: currently we ignore user settings on such servers, falling back to defaults. As I wrote at #261 (comment) (reviewing @chrisbobbe's PR which introduced support for user settings and skipped it for those old servers):
Cool, sounds good. This does seem like a spot where properly supporting both old and new versions would be kind of a pain. (Would have been totally doable, if the timing were such that we had to — we'd probably use a readValue that would just be one more spot that needs another line or two of code per setting — but enough of a pain to not be worth it given that we don't have to.)
The assumption that relies on is that we will desupport server 4.x (or if not then go back and deal with the old settings API after all) before launch.
The text was updated successfully, but these errors were encountered:
There is one spot where we already don't fully support older than server 5.x
(But in general we should avoid introducing more such places for now. As I wrote at #238 (comment) :
We'll probably bump that version higher sometime soon. But until we do that explicitly, I'd like to keep the code uniformly supporting the version we say we're supporting. That helps keep it manageable to be able to look at a piece of code and then at the API docs and confirm the code is behaving as it should, and to avoid accidentally leaving out something we need on newer versions.
When we do this, we should probably express the check in terms of a Zulip feature level, rather than a Zulip Server version in a form like "5.0". See chat discussion.
OTOH when the check fails and we're giving an error message to the user, that explanation should probably say the minimum is "Zulip Server 5.0". So for example:
Currently the app works with any Zulip Server version 4.x or newer. This is documented in our README and reflects what's documented at https://zulip.readthedocs.io/en/latest/overview/release-lifecycle.html . With #267, we'll start giving an explicit error if the user tries to connect to an older server.
At some point we'll want to increase that minimum to 5.x. As recorded at https://blog.zulip.com/tag/major-releases/ , 4.0 was released in 2021-05, over 2 years ago, and 5.0 in 2022-03, approaching 1.5 years ago.
When we do, we can follow up by sweeping the codebase for
TODO(server-5)
comments and acting on all of those. That will be in the same spirit as zulip/zulip-mobile#5100 and zulip/zulip-mobile#5192 in the old zulip-mobile RN app. (And zulip/zulip-mobile#5708, though that's a draft that was made moot by our migration to Flutter.)There is one spot where we already don't fully support older than server 5.x: currently we ignore user settings on such servers, falling back to defaults. As I wrote at #261 (comment) (reviewing @chrisbobbe's PR which introduced support for user settings and skipped it for those old servers):
The assumption that relies on is that we will desupport server 4.x (or if not then go back and deal with the old settings API after all) before launch.
The text was updated successfully, but these errors were encountered: