Add Zenodo concept DOI and date-released to CITATION.cff

.claude/skills/cut-a-release/SKILL.md

@@ -66,7 +66,7 @@ git checkout -b release/X.Y
 
 For a patch release on an existing line, check out the existing `release/X.Y` instead of creating one.
 
-## Step 4 — Bump the version in all three metadata files
+## Step 4 — Bump the version in all three metadata files, and refresh `date-released`
 
 The version is duplicated in three places and they must match exactly:
 
@@ -77,10 +77,18 @@ The version is duplicated in three places and they must match exactly:
 | `meta.yaml`      | `version` under `package`   |
 
 There is no `__version__` in the package source — the version is read from package metadata, so
-these three files are the whole job.
+these three files are most of the job.
+
+Also set `CITATION.cff`'s `date-released` to the actual release date (`YYYY-MM-DD`, **quoted** — an
+unquoted value parses as a YAML date rather than a string and fails CFF validation), i.e. the date
+Step 7 will push the tag, not the date the release branch was created. If the branch sits open for a
+few days before tagging, come back and correct it just before tagging rather than leaving the
+branch-creation date. This field is easy to forget because it lives right next to the fields in the
+table above but isn't one of the three cross-checked versions below — nothing catches it going stale.
 
 `scripts/check_metadata.py` runs as an `always_run` pre-commit hook and verifies that the name,
-description, and version all agree across the three files. It is your safety net here, but run it
+description, and version all agree across the three files — it does **not** check `date-released`,
+so it will not catch a stale or missing one. It is your safety net for the version fields; run it
 deliberately rather than discovering a mismatch at commit time:
 
 ```bash
@@ -138,6 +146,10 @@ If `main` moves while the PR is open, rebase the release branch onto it and reso
 
 Only once the maintainer is satisfied with the branch. The tag must be annotated **and signed**.
 
+Before tagging, check `CITATION.cff`'s `date-released` still matches today — the release branch may
+have sat open for days since Step 4 set it. If it's stale, fix it, commit, and re-run
+`pre-commit run --all-files` before tagging.
+
 ```bash
 git checkout release/X.Y && git pull
 git tag -s X.Y.Z -m "Version X.Y.Z"

CHANGELOG.md

@@ -16,6 +16,11 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   non-CCSDS definitions must pass `root_container_name` (the default is `CCSDSPacket`), and shows
   how a custom generator is passed to `create_dataset`. The Examples page links to the new script.
   [#190](https://github.com/lasp/space_packet_parser/issues/190)
+- Add the Zenodo concept DOI (`10.5281/zenodo.7735001`) and `date-released` to `CITATION.cff`, so the
+  citation metadata carries a persistent identifier and a release year rather than only the
+  repository URL. GitHub's "Cite this repository" widget reads both. The concept DOI is
+  version-agnostic and always resolves to the latest release, so it needs no maintenance at release
+  time. [#280](https://github.com/lasp/space_packet_parser/issues/280)
 
 ### Fixed
 

CITATION.cff

@@ -3,6 +3,7 @@ message: "If you use this software, please cite it as below."
 title: 'space_packet_parser'
 type: software
 version: '6.2.0'
+date-released: "2026-09-13"
 license: BSD-3-Clause
 abstract: The Space Packet Parser Python library is a generalized, configurable packet decoding library for CCSDS telemetry
     packets based on the XTCE standard for packet structure definitions. It supports complex and polymorphic
@@ -31,3 +32,7 @@ contact:
   orcid: "https://orcid.org/0000-0002-3520-9715"
 repository-code: "https://github.com/lasp/space_packet_parser"
 url: "https://space-packet-parser.readthedocs.io"
+identifiers:
+- type: doi
+  value: 10.5281/zenodo.7735001
+  description: Concept DOI resolving to the latest release of space_packet_parser

docs/source/developers.md

@@ -75,7 +75,8 @@ That is,
 
 2. Bump the version of the package to the version you are about to release by manually editing the `version` field in the `[project]` section of `pyproject.toml`.
 
-3. Update the version identifier in `CITATION.cff` and `meta.yaml`.
+3. Update the version identifier in `CITATION.cff` and `meta.yaml`, and set `date-released` in
+   `CITATION.cff` to the release date (`YYYY-MM-DD`, quoted).
 
 4. Update `CHANGELOG.md` to ensure the release notes for the version to be published is at the top
    and revisit `README.md` to keep it up to date.