chore(main): release 1.11.2

[github-actions]

🤖 I have created a release beep boop

1.11.2 (2026-10-14)

Documentation

• async: document the Python 3.15 limit of garbage-collected connection cleanup (#909) (a0ec6a6)

---

This PR was generated with Release Please. See documentation.

[yeongseon]

Do not merge this candidate as generated. Its version and notes are wrong.

This candidate was prepared after 1.11.1 was abandoned (see #838; fix #909) by following RELEASING.md's abandoned-release row: remove autorelease: pending from #838, then dispatch Prepare release (run 38571029848).

• What release-please did. It looked for the v1.11.1 tag, which does not exist because nothing was published. It then logged "No latest release found ... a previous version (1.11.1) was specified in the manifest" and fell back to the configured bootstrap-sha 78bcbc7 (the v1.8.0 commit). The candidate therefore re-lists every commit since 1.8.0, including feat commits already shipped in 1.9.0 to 1.11.0 (feat(python): declare Python 3.15 support #807, feat(python): require Python 3.11 or later #703, feat(types): bind SET, MULTISET and SEQUENCE values through pycubrid typed collections #623), and that is why it bumps to 1.12.0.
• What it should be. Since the last published tag v1.11.0 there are only fix and docs commits, so the expected candidate is the patch 1.11.2. Its notes should be the docs(async): document the Python 3.15 limit of garbage-collected connection cleanup #909 Documentation entry, with the unpublished ## [1.11.1] entries folded in.
• The fold did not happen either. ## [1.11.1] is still a separate section below ## [1.12.0].
• Why RELEASING.md's expectation failed. The row says "the next version is computed from the commits after the X.Y.Z merge". That does not hold when the abandoned version has no tag: release-please cannot locate the X.Y.Z merge as a release.

A maintainer needs to choose a remedy, for example:

• set bootstrap-sha in release-please-config.json to the 1.11.1 merge 37d0b0bd72cfee9d77a164e1a697721533e64acb. It applies only while no release tag is found, so it stops mattering once v1.11.2 exists. Then regenerate and fold [1.11.1] under autorelease: review;
• or freeze this PR with autorelease: review and correct the version, notes and fold on the branch by hand.

Not frozen, so it can still be regenerated.

[yeongseon]

Update: this candidate is now correct (1.11.2). It supersedes my earlier do-not-merge comment.

• Base fixed. ci(release): start release preparation after the abandoned 1.11.1 merge #912 set last-release-sha to the 1.11.1 merge 37d0b0b. The Prepare release dispatch 38573173509 logged "Using configured lastReleaseSha 37d0b0b… as last commit" and found 2 commits (docs(async): document the Python 3.15 limit of garbage-collected connection cleanup #909 docs, ci(release): start release preparation after the abandoned 1.11.1 merge #912 ci), so the candidate is 1.11.2. The branch is 0 commits behind main.
• Fold done. The PR is frozen with autorelease: review. Commit 2bb1fc7 folds the unpublished ## [1.11.1] entries into ## [1.11.2] under the standard headings, with an upgrade note that 1.11.1 was never published. A line-by-line diff shows nothing was lost.
• Checks. On 2bb1fc7:
  • make release-check VERSION=1.11.2 passed;
  • the extracted notes end with compare/v1.11.0...v1.11.2;
  • CI was restarted by close/reopen: 18 checks passed, none failed;
  • GitHub lists no closing issues.
• Labels. Keep autorelease: review through merge. autorelease: pending is the normal pre-publication label.
• Merge. Left to the maintainer.
• Follow-up after v1.11.2 is tagged. Remove last-release-sha in a normal PR (RELEASING.md). It is already inert once that tag exists.