Bump version: 4.3.0 → 4.4.0

[vhmartinezm]

TL;DR

Release bump for 4.4.0, the hunt-page ruleset tracking release (#266). Three lines: pyproject.toml version + [tool.bumpversion] current_version, and src/polyswarm/__init__.py. No code change.

Requires

• polyswarm-api Release 4.4.0 (develop → master) on PyPI before this repo's own develop → master merge — pyproject.toml already pins polyswarm_api>=4.4.0, and PyPI only publishes on a version change on master.
• Merging this into develop publishes nothing; the release fires when the follow-up develop → master PR lands.

[claude]

Release bump reviewed against AGENTS.md §Gitflow, specs/00-overview.md §Versioning, and specs/05-sdk-contract.md §Version pin. The three version sites are consistent (pyproject.toml [project] version + [tool.bumpversion] current_version + src/polyswarm/__init__.py), minor is the right increment per §Publication ("let the release be at least a minor"), the SDK pin is already polyswarm_api>=4.4.0 from #266 so no pin work belongs here, and nothing in the tree asserts a literal version string. Two doc/tooling notes, no blockers on the code.

1. Spec drift — the docs have no vehicle for this PR (AGENTS.md:44, specs/00-overview.md:80)

Both say version bumps "belong to the develop → master step":

Don't bump the version inside a feature PR unless the maintainer specifically asks — version bumps belong to the develop → master step.

But a develop → master PR merges develop's existing content — the bump commit has to be on develop first, which is exactly what this release-4.4.0 → develop PR does. As written, the docs describe a two-branch flow with nowhere for the bump to land, so a reader checking this PR against them sees a violation where there isn't one. Worth adding the missing step in this PR (it's a two-line edit to the same release policy the PR is enacting): release-bump PR → develop, then develop → master fires PyPI. specs/00-overview.md:11 and the #242 incident note stay as-is.

2. bump-my-version does not update the field that fires the release (pyproject.toml:54)

[[tool.bumpversion.files]] lists only src/polyswarm/__init__.py. bump-my-version bump minor rewrites [tool.bumpversion] current_version and __init__.py, but leaves [project] version — the one CI watches on master — at the old value. This PR hand-edited all three, so it is correct as landed; the gap bites whoever reaches for the tool instead, and it fails silently (bump commit, no PyPI publish). If you add an entry for it, anchor the search so it does not also match current_version = "...":

[[tool.bumpversion.files]]
filename = "pyproject.toml"
search = "\nversion = \"{current_version}\""
replace = "\nversion = \"{new_version}\""

Fine to defer, but not to the develop → master PR — that is when the unbumped field would matter.

Two things for the follow-up develop → master PR, per specs/05-sdk-contract.md §Publication:

• I could not verify from this environment whether polyswarm-api 4.4.0 is on PyPI yet. The ## Requires note correctly identifies it as a release-time (not merge-time) precondition — "This repo cannot be released before that SDK release exists" — so it needs re-checking at cutoff, and a floor of >=4.4.0 shipping to master ahead of the SDK release would break pip install polyswarm for everyone.
• That PR is the only place user-visible behaviour changes get announced ("This repo has no CHANGELOG... A note that lives only in a spec is not a release note"). Anything in Render hunt-page ruleset tracking and hunt provenance fields #266 that alters what an unchanged command line prints — the rules list output the hunt-page/tracking fields feed — should be listed there.

Cassette user-agents still read polyswarm_api/4.3.0; harmless, vcrpy's default match_on is method/scheme/host/port/path/query and ignores headers, and they record the SDK version regardless.