Forward-port SDK 2.1.0 changes to master

.github/workflows/tests.yml

@@ -2,9 +2,9 @@ name: Tests
 
 on:
   push:
-    branches: [master]
+    branches: [master, 'support/**', 'release/**']
   pull_request:
-    branches: [master]
+    branches: [master, 'support/**', 'release/**']
 
 permissions:
   contents: read

RELEASENOTES.md

@@ -1,5 +1,42 @@
 # Release Notes
 
+## 2.1.0
+
+### New Feature
+
+`HTTPError` and `RateLimitError` now keep the response headers from the
+failed request. `ExecutionContext.fetch()` already exposed headers on
+successful `FetchResponse` objects; it now also sets `exc.headers` when it
+raises. Integrations can read provider headers that are needed to handle a
+failure, for example the `X-Allow-Duplicates` override code that JobAdder
+returns with HTTP 409.
+
+```python
+try:
+    await context.fetch(url, method="PUT", json=body)
+except HTTPError as exc:
+    code = next(
+        (v for k, v in exc.headers.items() if k.lower() == "x-allow-duplicates"),
+        None,
+    )
+    if exc.status == 409 and code:
+        return ActionError(message=f"{exc}. Retry with allow_duplicates={code} if intended.")
+    raise
+```
+
+### Compatibility
+
+- `headers` is an optional, keyword-only constructor argument. Existing
+  `HTTPError(status, message, response_data)` calls are unchanged, and
+  `exc.headers` is `{}` when no headers are given.
+- The exception message is unchanged (`HTTP {status}: {message}`). Headers are
+  never added to `str(exc)`, so they do not reach the platform error result,
+  logs or the agent unless an integration returns them on purpose. Return only
+  the specific header values a caller needs, and match header names
+  case-insensitively.
+- `RateLimitError.retry_after` and the retry behaviour of `fetch()` are
+  unchanged.
+
 ## 2.0.1
 
 ### Behavior Change

RELEASING.md

@@ -1,8 +1,44 @@
 # Releasing the SDK
 
+## Development and support branches
+
+`master` tracks the next development version. When it has moved to a new
+major version, use a support branch to release changes for the previous
+major version without including incompatible development changes.
+
+For example, `master` is on `3.0.0.dev0`, while `release/2.1.0` was created
+from the `2.0.1` tag for the 2.1.0 release. This preserves the User-Agent
+revert in 2.0.1; the 3.x development line retains the User-Agent change.
+
+1. Create `release/<target-version>` from the appropriate published release
+   tag, not from `master`. For a later maintenance release, start from the
+   latest applicable release tag so earlier fixes are retained.
+2. Open feature and fix PRs against that release branch. Keep changes
+   compatible with the supported major version and use semantic versioning:
+   additive APIs can require a minor release rather than a patch release.
+3. Keep tests enabled for `master`, `release/**`, and any `support/**` branches in the workflow's
+   push and pull-request filters. Require successful tests before merging.
+4. After the changes are merged and verified on `release/<target-version>`, build and tag
+   the release from that line, not from `master`, using the checklist below.
+5. Forward-port applicable fixes, features, tests, and workflow changes to
+   `master` through a separate PR. Cherry-pick or reapply the selected changes;
+   do not merge the whole support branch into `master`. Retain `master`'s
+   development version and intentional behavior differences, update its
+   release notes as appropriate, and regenerate API docs from its source.
+
+Keep feature changes separate from release-version commits where practical
+to make forward-porting easier. Keep support branches while maintenance is
+needed; they do not need to be merged back when a release is finished.
+Existing integration dependency pins must be checked separately: for example,
+`~=2.0.0` and `~=2.0.1` do not select 2.1.0 automatically.
+
+## Release checklist
+
 * Use semantic versioning
 
-* Create a release branch (`release/<a.b.c>`)
+* Create or use the release branch (`release/<a.b.c>`): start from `master`
+  for its release, or the appropriate published tag for a supported-version
+  release as described above.
 
 * Update `pyproject.toml` as required:
     - Version 
@@ -63,4 +99,4 @@
     View at:
     https://pypi.org/project/autohive-integrations-sdk/<a.b.c>/
 
-    ```
+    ```

docs/apidocs/autohive_integrations_sdk.html

@@ -45,13 +45,13 @@ <h2>API Documentation</h2>
                     <h1 class="modulename">
 autohive_integrations_sdk    </h1>
 
-
+                
                         <input id="mod-autohive_integrations_sdk-view-source" class="view-source-toggle-state" type="checkbox" aria-hidden="true" tabindex="-1">
 
                         <label class="view-source-button" for="mod-autohive_integrations_sdk-view-source"><span>View Source</span></label>
 
                         <div class="pdoc-code codehilite"><pre><span></span><span id="L-1"><a href="#L-1"><span class="linenos">1</span></a><span class="c1"># Version</span>
-</span><span id="L-2"><a href="#L-2"><span class="linenos">2</span></a><span class="n">__version__</span> <span class="o">=</span> <span class="s2">&quot;3.0.0.dev0&quot;</span>
+</span><span id="L-2"><a href="#L-2"><span class="linenos">2</span></a><span class="n">__version__</span> <span class="o">=</span> <span class="s2">"3.0.0.dev0"</span>
 </span><span id="L-3"><a href="#L-3"><span class="linenos">3</span></a>
 </span><span id="L-4"><a href="#L-4"><span class="linenos">4</span></a><span class="c1"># Re-export classes from integration module</span>
 </span><span id="L-5"><a href="#L-5"><span class="linenos">5</span></a><span class="kn">from</span><span class="w"> </span><span class="nn">autohive_integrations_sdk.integration</span><span class="w"> </span><span class="kn">import</span> <span class="p">(</span>