Export PyPI Package Release History

Release history helps teams study maintenance cadence and compatibility changes, but the raw PyPI response can contain many file objects. The PyPI Package Scraper produces bounded summaries suitable for a dataset row.

Enable release summaries deliberately

Request only the projects and history depth needed for the question.

{"packageNames":["pip","setuptools","wheel","uv"],"includeReleases":true,"maxReleasesPerPackage":20,"maxResults":4}

Each summary contains version, first file upload time, file count, combined byte size, a Python requirement value, and whether all represented files are yanked. The package row also retains the current metadata and project URL.

Validate ordering and dates for several releases against PyPI before calculating cadence. Some versions have multiple uploads, files can differ in requirements, and releases without files are omitted. The summary is intentionally compact; use the official project pages when file-level hashes, wheel tags, or individual upload details matter.

For monitoring, store one snapshot per collection or flatten summaries into a release table keyed by package and version. Do not infer semantic compatibility solely from version numbering. A yanked release should be investigated in official metadata and project notes, not silently deleted from historical analysis.

Cadence metrics also need context. Mature libraries may release slowly, while active prerelease programs produce many versions. Combine quantitative history with changelogs, repository activity, ownership, and adoption evidence. The export removes collection friction without pretending that release frequency measures package quality.

If release dates drive a report, retain the upstream timestamp rather than substituting the Actor run time, which measures collection instead of publication.