api_docs: Update API docs for presence changes.

api_docs/changelog.md

@@ -20,6 +20,14 @@ format used by the Zulip server that they are interacting with.
 
 ## Changes in Zulip 7.0
 
+**Feature level 178**
+
+* `POST users/me/presence`, [`POST /register`](/api/register-queue),
+  [`GET /events`](/api/get-events), `GET /realm/presence`, `GET
+  /users/<user_id_or_email>/presence`: The server no longer stores
+  which client submitted presence data, and presence responses from
+  the server will always contain the `aggregated` and `website` keys.
+
 **Feature level 177**
 
 * [`GET /messages`](/api/get-messages),

version.py

@@ -33,7 +33,7 @@ DESKTOP_WARNING_VERSION = "5.4.3"
 # Changes should be accompanied by documentation explaining what the
 # new level means in api_docs/changelog.md, as well as "**Changes**"
 # entries in the endpoint's documentation in `zulip.yaml`.
-API_FEATURE_LEVEL = 177
+API_FEATURE_LEVEL = 178
 
 # Bump the minor PROVISION_VERSION to indicate that folks should provision
 # only when going from an old version of the code to a newer version. Bump

zerver/openapi/zulip.yaml

@@ -1069,6 +1069,11 @@ paths:
                                       `{client_name}`: Object containing the details of the user's
                                       presence on a particular platform. The object key is the client's
                                       platform name, for example `website` or `ZulipDesktop`.
+
+                                      **Changes**: Starting with Zulip 7.0 (feature level 178), this
+                                      will always contain two keys, `website` and `aggregated`, with
+                                      identical data. The server no longer stores which client submitted
+                                      presence updates.
                                     additionalProperties: false
                                     properties:
                                       client:
@@ -7292,8 +7297,12 @@ paths:
                             There is also an `aggregated` key, which matches the contents of the object
                             that has been updated most recently.
 
-                            For most applications, you'll just want to look at the
-                            `aggregated` key.
+                            For most applications, you'll just want to look at the `aggregated` key.
+
+                            **Changes**: Starting with Zulip 7.0 (feature level 178), this
+                            will always contain two keys, `website` and `aggregated`, with
+                            identical data. The server no longer stores which client submitted
+                            presence updates.
                     example:
                       {
                         "presence":
@@ -17244,6 +17253,11 @@ components:
         There is also an `aggregated` key, which matches the contents of the object
         that has been updated most recently (except for the `pushable` value which is
         not present).
+
+        **Changes**: Starting with Zulip 7.0 (feature level 178), this
+        will always contain two keys, `website` and `aggregated`, with
+        identical data. The server no longer stores which client submitted
+        presence updates.
       additionalProperties: false
       properties:
         client: