[oss-candidate] rework r1: jbetancur/react-data-table-component#1394

[askalf]

Maintainer said

jbetancur, 2026-09-22T11:16:48Z, on CHANGELOG.md line 21 (jbetancur#1394 (comment)):

Sorry I should have been more clear. This needs to land in a new entry for 8.10.1 since 8.10.0 was already released

Context: v8.10.0 was tagged on 2026-09-06 (a3473b0 chore: release v8.10.0 [skip ci]). At the submitted head 92f7524 the bullet for this fix sat under ## 8.10.0 / ### Bug fixes, i.e. inside a section that has already shipped.

Change

CHANGELOG.md:5-12 (one commit, 63253d8, docs: file the pinned scrollbar fix under a new 8.10.1 changelog entry): a new ## 8.10.1 section with its own ### Bug fixes heading and --- separator is inserted above ## 8.10.0, in the file's existing format; the bullet moves there unchanged, and the ## 8.10.0 section is restored byte-for-byte to upstream master. No other file changes in this round.

Diff of CHANGELOG.md against upstream master (424d21c) at this head:

@@ -2,6 +2,14 @@

 A summary of notable changes per release. For the full commit history see the [repository on GitHub](https://github.com/jbetancur/react-data-table-component/commits/master).

+## 8.10.1
+
+### Bug fixes
+
+- **Pinned scrollbar** now sets `aria-controls` to the scroll container's real id. When the container already carried an id, or was labelled again after an unpin and re-pin, the thumb kept pointing at a generated id no element had, so assistive technology could not resolve what the scrollbar controlled.
+
+---
+
 ## 8.10.0

 ### New features

Evidence, using the exact awk the release workflow runs to extract release notes (.github/workflows/release.yml:101):

== submitted head 92f7524: extract 8.10.1 ==
(rc=0 ; lines: 0)
== submitted head: grep Pinned scrollbar in 8.10.0 section ==
1
== worktree after change: extract 8.10.1 ==

### Bug fixes

- **Pinned scrollbar** now sets `aria-controls` to the scroll container's real id. When the container already carried an id, or was labelled again after an unpin and re-pin, the thumb kept pointing at a generated id no element had, so assistive technology could not resolve what the scrollbar controlled.

== worktree after change: Pinned scrollbar in 8.10.0 section ==
0
== 8.10.0 section identical to upstream master ==
IDENTICAL

So before the change, a future 8.10.1 release would have extracted empty notes and the bullet would have been misfiled under a shipped version; after it, the 8.10.1 extraction yields exactly this bullet and the 8.10.0 section is the released one.

Branch diff against upstream master at this head: CHANGELOG.md +8, CLAUDE.md (pre-existing, merge-base drift: upstream jbetancur#1395 changed the same line after our branch point), src/__tests__/pinning.test.tsx +193, src/components/PinnedScrollbar.tsx +6/-1. Only CHANGELOG.md differs from the submitted head 92f7524.

CI chain (npm run lint && npm run typecheck && npm test && npm run build, as .github/workflows/ci.yml runs it): see ## CI below.

CI

Local run of the exact chain .github/workflows/ci.yml executes (npm ci, npm run lint, npm run typecheck, npm test scoped to the touched test file, npm run build) at 63253d8, Node v24.19.0 (log: /agent-output/oss/react-data-table-component/r1-ci-chain.log):

added 460 packages in 10s
LINT_OK
TSC_OK
 ✓ src/__tests__/pinning.test.tsx (24 tests) 627ms
 Test Files  1 passed (1)
      Tests  24 passed (24)
   Duration  3.13s (environment 42%, transform 25%, tests 21%, import 6%, setup 5%)
TEST_OK
BUILD_OK

Nothing in eslint.config.js, tsconfig.json, tsup.config.ts or vitest.config.ts reads CHANGELOG.md, so the only tool that consumes it is the release workflow's awk extraction shown above. Fork CI: gh pr checks 2 reports no checks (the fork's ci.yml triggers on pull_request to master only, and this staging PR targets the feature branch; upstream CI at 92f7524 was already green after the previous round). Upstream CI at the new head will run once the Scout fast-forwards the submitted branch; the maintainer must approve the fork workflow as before.

Reply

Moved the entry into a new ## 8.10.1 section above ## 8.10.0 in 63253d8, with its own ### Bug fixes heading in the file's format. The ## 8.10.0 section is now identical to master again, and the release workflow's notes extraction for 8.10.1 returns just this bullet.