Bump version and changelog for release

docs/changelog.rst

@@ -12,6 +12,94 @@ to a major new version of the SDK.
 
 .. scriv-insert-here
 
+.. _changelog-3.20.0:
+
+v3.20.0 (2023-06-05)
+--------------------
+
+* Implemented ``FlowsClient.get_run(...)`` (:pr:`721`)
+
+* Implemented ``FlowsClient.get_run_logs(...)`` (:pr:`722`)
+
+* Implemented ``SpecificFlowClient.resume_run(...)`` (:pr:`723`)
+
+* Behavior has changed slightly specifically for ``TimerAPIError``. When parsing
+  fails, the ``code`` will be ``Error`` and the ``messages`` will be empty. The
+  ``detail`` field will be treated as the ``errors`` array for these errors
+  when it is present and contains an array of objects.
+
+* ``ConsentRequiredInfo`` now accepts ``required_scope`` (singular) containing
+  a single string as an alternative to ``required_scopes``. However, it will
+  parse both formats into a ``required_scopes`` list. (:pr:`726`)
+
+* ``FlowsClient.list_flows`` now supports passing a non-string iterable of
+  strings to ``orderby`` in order to indicate multiple orderings (:pr:`730`)
+
+* Support ``pathlib.Path`` objects as filenames for the JSON and sqlite token storage adapters. (:pr:`734`)
+
+* Several ``TransferClient`` methods, ``TransferData``, and ``DeleteData`` now support the ``local_user``, ``source_local_user``, and ``destination_local_user`` parameters  (:pr:`736`)
+
+* The TransferRequestsTransport will no longer automatically retry errors with a code of EndpointError
+
+* Fix pagination on iterable gcs client routes  (:pr:`738`, :pr:`739`)
+
+  * ``GCSClient.get_storage_gateway_list``
+
+  * ``GCSClient.get_role_list``
+
+  * ``GCSClient.get_collection_list``
+
+  * ``GCSClient.get_user_credential_list``
+
+
+* Error parsing in the SDK has been enhanced to better support JSON:API and
+  related error formats with multiple sub-errors. Several attributes are
+  added or changed. For most SDK users, the changes will be completely
+  transparent or a minor improvement. (:pr:`725`)
+
+  * Error parsing now attempts to detect the format of the error data and will
+    parse JSON:API data differently from non-JSON:API data. Furthermore,
+    parsing is stricter about the expectations about fields and their types.
+    JSON:API parsing now has its own distinct parsing path, followed only when
+    the JSON:API mimetype is present.
+
+  * A new attribute is added to API error objects, ``errors``. This is a list
+    of subdocuments parsed from the error data, especially relevant for
+    JSON:API errors and similar formats. See the
+    :ref:`ErrorSubdocument documentation <error_subdocuments>` for details.
+
+  * A new attribute is now present on API error objects, ``messages``. This is
+    a list of messages parsed from the error data, for errors with multiple
+    messages. When there is only one message, ``messages`` will only contain
+    one item.
+
+  * The ``message`` field is now an alias for a joined string of
+    ``messages``. Assigning a string to ``message`` is supported for error
+    subclasses, but is deprecated.
+
+  * ``message`` will now be ``None`` when no messages can be parsed from the error data.
+    Previously, the default for ``message`` would be an alias for ``text``.
+
+  * All error types now support ``request_id`` as an attribute, but it will
+    default to ``None`` for errors which do not include a ``request_id``.
+
+  * An additional field is checked by default for error message data,
+    ``title``. This is useful when errors contain ``title`` but no
+    ``detail`` field. The extraction of messages from errors has been made
+    stricter, especially in the JSON:API case.
+
+  * The ``code`` field of errors will no longer attempt to parse only the first
+    ``code`` from multiple sub-errors. Instead, ``code`` will first parse a
+    top-level ``code`` field, and then fallback to checking if *all* sub-errors
+    have the same ``code`` value. The result is that certain errors which would
+    populate a non-default ``code`` value no longer will, but the ``code`` will
+    also no longer be misleading when multiple errors with different codes are
+    present in an error object.
+
+  * The ``code`` field of an error may now be ``None``. This is specifically
+    possible when the error format is detected to be known as JSON:API and
+    there is no ``code`` present in any responses.
+
 .. _changelog-3.19.0:
 
 v3.19.0 (2023-04-14)

src/globus_sdk/version.py

@@ -1,3 +1,3 @@
 # single source of truth for package version,
 # see https://packaging.python.org/en/latest/single_source_version/
-__version__ = "3.19.0"
+__version__ = "3.20.0"