Context
We published v5 of the Zenodo bulk-data archive with a substantial set of changes (annotation CSVs, mapped-variant JSON, VA-Spec NDJSON, namespaced columns) but no changelog, so data consumers had no way to see what changed between versions. We want a changelog to be a standing part of every release going forward.
Done (in working tree — needs PRs)
mavedb-api:
- Add
src/mavedb/scripts/resources/CHANGELOG.md (canonical, Keep-a-Changelog style) with the v5 entry.
export_public_data.py should bundles CHANGELOG.md into the zip and its docstring should point at the changelog + runbook.
- Add
CHANGELOG.md to the archive-structure diagram in resources/README.md.
deployment:
- Add
docs/zenodo-release.md release runbook (write changelog first → generate → verify → upload as a new Zenodo version → mirror notes → update docs), with a checklist.
Outstanding
Context
We published v5 of the Zenodo bulk-data archive with a substantial set of changes (annotation CSVs, mapped-variant JSON, VA-Spec NDJSON, namespaced columns) but no changelog, so data consumers had no way to see what changed between versions. We want a changelog to be a standing part of every release going forward.
Done (in working tree — needs PRs)
mavedb-api:src/mavedb/scripts/resources/CHANGELOG.md(canonical, Keep-a-Changelog style) with the v5 entry.export_public_data.pyshould bundlesCHANGELOG.mdinto the zip and its docstring should point at the changelog + runbook.CHANGELOG.mdto the archive-structure diagram inresources/README.md.deployment:docs/zenodo-release.mdrelease runbook (write changelog first → generate → verify → upload as a new Zenodo version → mirror notes → update docs), with a checklist.Outstanding
CHANGELOG.mdentry into the record's version notes/description (v5 shipped without them).