[JarryShaw]

Please follow the guide below

• Searched for similar pull requests
• Followed the coding style
• make test passes, and a test case covers the change (tests/project/test_pr_template_commit_types_1102_unit.py and tests/project/test_python_versions_update_1660.py run)
• Described the user-visible change below and left its changelog entry to the maintainer (N/A)

What is the purpose of your pull request?

• chore — anything else

---

Description of your pull request and other information

Closes #2449

Feature PRs no longer add entries under docs/source/changelog/ or to CHANGELOG.md; the maintainer writes them centrally. CONTRIBUTING.md says so, and this PR also rewords the template's changelog box to match (not deferred). util/update_python_versions.py and its test follow the new box wording. No runtime code or release content changed.

[JarryShaw]

NEEDS CHANGES (Sonnet, 30953ed00). CONTRIBUTING.md change is correct and contained; no code, release content or counts changed.

• .github/PULL_REQUEST_TEMPLATE.md still tells contributors to add an entry and regenerate CHANGELOG.md, and links to the section this PR rewrites. Reword it in this PR, with util/update_python_versions.py (~L1301) and tests/project/test_python_versions_update_1660.py (~L879), which pin the current wording.
• If the template is instead deferred, the body must say so and Closes #2449 becomes Refs #2449.
• Non-blocking: "Feature pull requests" (L61) is narrower than L28; "Open" (L61) is undefined; L28 is 125 columns.

[JarryShaw]

NEEDS CHANGES (Sonnet, 4f2af68ee). Regex and pinned test verified; no code changed.

• CONTRIBUTING.md ~L69 is 102 columns. Break before "the" so line 70 starts "the .rst entry, then regenerates:".
• PULL_REQUEST_TEMPLATE.md ~L10: "described … above" should say "below" (the description is below the checklist); update test_python_versions_update_1660.py ~L879 to match.
• Non-blocking: "Feature branches" (CONTRIBUTING ~L64), "docs-only" in the body (the diff touches util/ and tests/), "open versions" in the title.

[github-actions]

Coverage: 94.46% (unit tier, Python 3.15, ff31e282a, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	106	4	20	2	95.24%
pcapkit/const	20918	175	2908	156	98.57%
pcapkit/corekit	2918	77	942	38	96.81%
pcapkit/dumpkit	286	3	102	3	98.45%
pcapkit/foundation	3512	27	1218	32	98.75%
pcapkit/interface	138	4	52	3	96.32%
pcapkit/protocols	22840	157	5950	127	99.00%
pcapkit/toolkit	961	26	342	8	96.62%
pcapkit/utilities	574	7	156	5	98.36%
pcapkit/vendor	5590	2286	1280	214	55.75%

Per-file detail: the coverage-html artifact of this run.

[JarryShaw]

Local-only commit 30953ed forks from 4ca3f30 and is redundant with origin a9db8a4 (rebase onto origin is empty). Nothing to push. Local commit to be dropped.

[JarryShaw]

Add to convention and session/sweep memo: upon each release, amend inline or post updates in thread to the PEP's Discussion post. PEP doc is source of truth but aim to keep the Discussion also up-to-date.

[JarryShaw]

Ruling reconciled: upon each release, amend pep.rst inline and update Discussion #106 ("PyPCAPKit Enhancement Proposals") to match -- the page stays authoritative. Documented in process.rst (20f39eb73) and in the sweep memo.

[JarryShaw]

Owner ruling (2026-11-01), paraphrased: changelog entries are consolidated in this PR and stripped from the open feature PRs, so they stop conflicting. The ruling named #2383, which is a merged HIP fix, so I've taken it to mean this PR (it implements #2449's practice). Say so if that's wrong.

In flight on this branch: merge current main, add #2509's Radiotap entry, and reconcile the 1.6.0 entries this merge wave left stale. When that is pushed, the label resets to review: pending and a fresh review runs.

[JarryShaw]

Decision needed: how 1.6.0's release starts. Once this PR is in, the only release step left is the version, and main still says 1.5.1. util/bump_version.py would make that 1.5.1.post1, so 1.6.0 needs a hand edit: __version__ = '1.6.0' plus CITATION.cff's version and date-released, in one commit. This entry's heading also still reads 1.6.0 -- unreleased.

• (a) Fold the heading date and the version edit into this PR. Merging it is then the single push that starts the release.
• (b) Fold only the heading date here, and open a separate release PR for the version after this merges.

Recommendation: (a), because one merge means one release run and no second push to keep main quiet for. Until the version moves, a Vendor Update that finds a registry change after any green main push would bump to 1.5.1.post1. If a Create Release approval appears for that version, decline it.

[JarryShaw]

GOOD TO GO at 191a3c2c4. Since 5732de283, this merges main up to #2785 (f312f92f3). It also adds one Added entry for the new pcapkit.utilities.inspect.isabstract (#2784, #2785), placed with the other utilities entries and pointing at the registry entry below it. There is no Fixed entry, because the GraalPy defect never shipped. I checked the delta myself: it touches only the changelog files, the entry's roles resolve, the docs build adds no warnings, and changelog_md.py --check passes. Every 1.6.0 PR is now folded in. The question above about how the release starts is still open, and if the answer is (a) this gets one more round.

[JarryShaw]

take (a)

is the pep update-to-update? closing wave2? dont forget to post updates to Discussion as well

[JarryShaw]

Reconciled: (a) taken. The 1.6.0 heading date and the hand edit to 1.6.0 (__version__ plus CITATION.cff) go into this PR, so merging it is the single push that starts the release.

On the PEP page: I'm auditing its wave 2 section against what 1.6.0 shipped. Any update, including marking wave 2 closed, goes into this PR too, so it lands with the release. Discussion #106 (Enhancement Proposals) will get the wave 2 update. I'll report back here with the diff and a fresh verdict.

[JarryShaw]

The PEP page is not up to date. It marks wave 2 done (#2564), but:

• it never says wave 2 is released in 1.6.0;
• its wave 2 line leaves out the ICMP/ICMPv6 and LINUX_SLL/LINUX_SLL2 pairs;
• feat(internet): implement ICMP and ICMPv6 under an abstract ICMP base #2446 mis-edited the pairs paragraph;
• the Release Plan describes only 1.5.0;
• a few sections still describe 1.6.0 work as pending.

I'm folding the fixes into this PR so they land with the release, along with SECURITY.md's supported-versions table and the missing versionadded:: 1.6.0 on new modules. A fresh review and verdict follow.

Discussions: this repo has never posted release announcements. Progress has gone as replies under the matching #106 topic, so I'll post the wave 2 and reassembly updates there once the release publishes, when the links work. I'm posting the NGAP update on #251 now, since it has been true since 1.5.0.

[JarryShaw]

Owner ruling (in session, paraphrased): stop tracking waves. What is left is simply the remaining work, and the wave statements were internal decision tracking, so they come out entirely.

Here is how I'm applying it in this PR:

• pep.rst: remove the wave framing. The Delivery Sequence becomes the remaining work, and the release notes drop the wave labels.
• Changelog: the 1.6.0 intro and the summary bullet in changelog.rst (and the release: commit body) stop saying "Wave 2 of the roadmap".
• process.rst: its "each wave of" line goes.

Released changelogs (1.5.0) stay as shipped. The #106 updates will drop the wave wording too.

[JarryShaw]

GOOD TO GO at ff31e282a. This is the release: merging it is the single push that starts 1.6.0, and Create Release then waits for your approval.

Since 191a3c2c4:

• release: ship 1.6.0 (9da5992d8). The heading is dated 2026-11-05, and __version__ and CITATION.cff say 1.6.0.
• PEP page up to date (bd52f9bc7), and roadmap waves removed per your ruling (ff31e282a). The old Delivery Sequence is now "Remaining Work", and the Release Plan drops its wave labels.
• Also: SECURITY.md lists 1.6.x as stable, and every module new in 1.6.0 gets versionadded.

Two Sonnet cross-reviews per round, one on content and one on the ruling, checked the work against v1.5.0, v1.5.1 and the code. No roadmap wave is left, the force-pushed history keeps the old trees exactly, every dropped fact is either restated or still in the changelog, and the anchors resolve. The docs build in the pinned venv adds no warnings. The 1.5.0 changelog is left as released.

[JarryShaw]

The squash merge (7a486b7e6) went in with its body cleared. At the owner's request, main was amended to bc75a127c, which has the same tree and parent and carries the message below. The 1.6.0 release now runs on bc75a127c.

- Changelog entries are written centrally by the maintainer, not per PR, so parallel PRs
  stop conflicting on one file; CONTRIBUTING.md, the PR template and
  util/update_python_versions.py say so.
- docs/source/changelog/1.6.0.rst records the user-visible changes since 1.5.1, dated
  2026-11-05, with CHANGELOG.md regenerated; 1.5.0's roles follow names moved since.
- Release 1.6.0: __version__ and CITATION.cff say 1.6.0, released 2026-11-05.
- The roadmap stops tracking waves: pep.rst is brought up to date for 1.6.0 and lists
  only the remaining work; the 1.6.0 intro, changelog.rst and process.rst drop waves.
- SECURITY.md lists 1.6.x as the current stable line, 1.5.x and older as unpatched.
- Modules new in 1.6.0 gain a versionadded on their docs pages and module docstrings.

Closes #2449