[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort)
• make test passes, and a test case covers the change
• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A, centralised per docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• fix — corrects a defect

---

Description of your pull request and other information

bump() in util/bump_version.py rebuilt a dev-release bump from
base_version plus the incremented devN, dropping any pre-release segment:
bump('1.6.0rc1.dev2') returned '1.6.0.dev3'. Version.is_devrelease is true
whenever dev is set regardless of pre, so that branch ran even when a
pre-release tag was present and never looked at it.

That is a real ordering regression, not just a lost string: under PEP 440 a bare
dev release (1.6.0.dev3) sorts before one carrying rc1
(1.6.0rc1.dev2), so the "bumped" version compared as older than the version it
was bumped from.

Fix: when is_devrelease is true, rebuild the pre-release segment from
ver_obj.pre (when set) before appending .devN, giving 1.6.0rc1.dev3. The
pre-release-only and post-release branches are unchanged, as is the no-pre-release
dev case (1.5.0.dev1 -> 1.5.0.dev2).

Added tests to tests/project/test_bump_version.py covering rc/a/b segments
on a dev bump, parsing the result back with packaging.version.Version to assert
.pre and .dev, and asserting the fixed ordering against the pre-fix version.
Confirmed both new cases fail against the old code before the fix.

Closes #2459

[JarryShaw]

Cross-review (different model, adversarial) came back NEEDS CHANGES. The rc/a/b fix is correct and verified — but the same bug remains for post-releases: bump('1.6.0.post1.dev0') still returns '1.6.0.dev1', which sorts older than the input. Root cause is identical: the dev branch rebuilds from base_version, which drops post as well as pre. Checked over 540 version-shape combinations; exactly the 240 with both post and dev set still regress.

Fix: carry the post segment through the same way the pre segment now is. Also flagged: the fixed docstring only mentions dropping pre, should mention post too.

Dispatching a fix to this branch now.

[JarryShaw]

Fixed and verified directly (new head 8e09acc55): bump() now carries forward both pre AND post segments through the dev-counter bump. bump('1.6.0.post1.dev0') → '1.6.0.post1.dev1', bump('1.6.0rc1.post1.dev2') → '1.6.0rc1.post1.dev3', both confirmed genuinely newer via packaging.version.Version. Added a looped test sweeping pre×post×epoch combinations. 37 passed/1 skipped, lint/mypy clean (no new findings).

[JarryShaw]

Cross-review (different model, adversarial) came back GOOD TO GO. Verified the fix over an exhaustive 53,760-input grid (epoch × release × pre × post × dev × local-label combinations) with zero ordering regressions, and confirmed the grid itself is valid by reproducing 53,280 regressions against pre-fix main. Mutation-tested: 3 of 3 briefed mutations caught by the suite. One non-blocking nit noted (the grid test doesn't cover .post0 alone) — not worth a revision on its own.

[github-actions]

Coverage: 94.44% (unit tier, Python 3.15, 8e09acc55, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	2	95.16%
pcapkit/const	19609	133	2620	120	98.84%
pcapkit/corekit	2605	74	818	37	96.52%
pcapkit/dumpkit	281	3	100	3	98.43%
pcapkit/foundation	3070	24	1072	26	98.79%
pcapkit/interface	138	4	52	3	96.32%
pcapkit/protocols	17593	193	4678	179	98.32%
pcapkit/toolkit	924	36	334	10	95.55%
pcapkit/utilities	502	7	144	5	98.14%
pcapkit/vendor	4449	1854	1020	167	55.11%

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