A dataset changes after it is first deposited far more often than researchers expect: a correction to a handful of rows, a re-run with an added variable, a merge of a second collection wave. Versioning is the practice of tracking those changes so that every citation, download, and reuse points to an exact, unambiguous state of the data — not a moving target. This guide covers the three practical questions that come up whenever a dataset changes: how to number versions, how a concept DOI differs from a version DOI in repositories like Zenodo and Dryad, and the judgment call of deciding whether a given change actually warrants a new version at all.
Quick-reference: does this change need a new version?
| Change | New version? | Why |
|---|---|---|
| Fixed a typo in the dataset title or description | No — edit metadata in place | No file content changed; the existing version DOI still points to correct data |
| Corrected a small number of erroneous values in a data file | Yes | Anyone who already cited or downloaded the old file is now looking at data you know is wrong |
| Added a codebook or README that was missing | Usually no, unless the repository treats added files as a content change | Supplementary documentation without altering the measured data is commonly handled as a metadata/file addition, not a new edition — but check your repository’s own policy, since some treat any file-list change as version-triggering |
| Added a new wave of data collection to an existing dataset | Yes | The set of observations a citation resolves to has materially changed |
| Reformatted files (e.g., .xls to .csv) with no change in values | Depends — often yes for traceability | Downstream scripts built against the old file structure may break even though the values are identical |
| Changed the license or access conditions | No — edit metadata in place | A rights/licensing change does not alter the deposited content itself |
| Removed a variable for a privacy or disclosure-risk reason | Yes | The content someone would download is now different from what earlier citations point to |
The general test (this is a widely used rule of thumb among data curators, not a formal standard): if someone who cited the DOI before your change would now retrieve materially different content than what they cited, mint a new version. If only the description, license, or discoverability metadata changed and the files are untouched, edit in place instead.
Version numbering schemes
There is no single mandated numbering scheme across the research-data ecosystem the way there is, for example, for software (Semantic Versioning). In practice, three approaches are in common use:
- Simple sequential integers — v1, v2, v3. This is what repositories built on Zenodo’s platform (InvenioRDM) generate automatically: every time you click “New version,” the next integer is assigned. It carries no information about how large the change was, only its order.
- Major.minor numbering (e.g., 1.0, 1.1, 2.0) — used when a project wants the number itself to signal scope: a minor-version bump for small corrections, a major-version bump for structural or content changes such as adding a new data collection wave. DataCite‘s metadata schema has a dedicated, free-text
Versionproperty for exactly this purpose, and its own guidance distinguishes minor content changes (same DOI, updatedVersionvalue, e.g. “1.1”) from major content changes (new DOI recommended, linked back to the earlier one). - Date-stamped releases (e.g., a dataset re-released annually as “2024 release,” “2025 release”) — common for datasets built from periodic surveys or continuously updated administrative data, where the release cadence is a more meaningful label to users than a version counter.
Whichever scheme you use, state it explicitly in the dataset’s README or documentation, and keep it consistent across the life of the dataset — a scheme that changes partway through (say, switching from integers to major.minor) makes it harder for anyone citing an old version to understand how it relates to the current one.
Concept DOI vs. version DOI
The single most common point of confusion in dataset versioning is the difference between a DOI that always resolves to the latest version of a dataset and a DOI that resolves to one specific, unchanging version. Repositories that support formal versioning — Zenodo is the clearest example, and other InvenioRDM-based repositories work the same way — mint both:
- Version DOI — assigned to one specific version’s files and metadata. It never changes what it points to. This is the DOI to cite when precision matters: a methods section, a replication package, anywhere the exact data used needs to be pinned down.
- Concept DOI — represents the dataset as an ongoing work across all of its versions and always resolves to whichever version is currently the most recent. This is the DOI to put on a lab website, a CV, or anywhere you want visitors to land on the current state of the dataset rather than a version that may since have been superseded.
Mechanically, on Zenodo, creating a new version generates a new record with its own version DOI, files, and metadata, but that record is linked to every past and future version of the same deposit, and the concept DOI is updated to point at the newest one. Older version DOIs remain resolvable and unchanged — nothing is overwritten. DataCite’s metadata schema supports the same relationship generically through relatedIdentifier relation types: IsNewVersionOf / IsPreviousVersionOf link one version directly to its predecessor, while HasVersion / IsVersionOf link a canonical (concept-style) DOI to its specific versioned instances. A repository does not have to use Zenodo’s concept-DOI model by name to support versioning — any repository that populates these relation types correctly is doing the same job under a different label. This is the same DOI infrastructure documented in the FAIR Data Principles entry, since a resolvable, unambiguous version identifier is part of what makes a dataset Findable and Accessible in practice.
Practical rule: cite the version DOI in a methods section or data-availability statement; use the concept DOI (or the dataset’s landing page) when pointing readers to “the dataset” as an evolving resource. Not every repository offers a concept DOI — check your specific repository’s documentation before assuming the distinction is available; some smaller or institutional repositories only mint one DOI per dataset and handle updates purely through metadata revision history instead.
What actually changes when you mint a new version
Understanding what a new version does and does not do helps with the when-to-version judgment call above:
- A new version is a new, separate record with its own persistent identifier, own file set, and own metadata — it does not overwrite or delete the previous version’s record.
- Citations to the old version DOI keep resolving to the old files. This is the entire point: reproducibility depends on being able to retrieve exactly what an earlier paper cited, even after the dataset has moved on.
- Some repositories let you reuse unchanged files across versions rather than re-uploading everything, which keeps storage costs down without weakening the version boundary.
- Download/citation counts are typically tracked per version and are also aggregated at the concept level, so a heavily-cited early version and a lightly-cited recent one both still contribute to the dataset’s overall visibility.
Where this fits in a data management plan
Funder and institutional data management plans increasingly expect an explicit versioning approach (see the Data Management Plan (DMP) entry for the broader planning context) to be described up front, not improvised after the first correction is needed. A short DMP passage covering (1) the numbering scheme you will use, (2) the threshold for what counts as a new version versus a metadata edit, and (3) which repository DOI (version or concept) will be cited in publications, closes a gap that otherwise tends to get resolved inconsistently, dataset by dataset, well after the data management plan itself has been approved.
Frequently asked questions
Is dataset versioning the same as data version control (like DVC or Git)?
No, though they solve a related problem at different scales. Data version control tools track incremental changes to files during active analysis — typically inside a lab’s own pipeline, often integrated with Git and used most heavily in machine-learning workflows. Dataset versioning as covered here is about the publication-facing act of minting a new, citable, persistent-identifier-bearing version when a deposited dataset changes. Many projects use both: DVC (or an equivalent) during active work, then a single considered version bump when a snapshot is deposited to a public repository. See the companion guide on DVC for research datasets and ML pipelines for the pipeline side of this.
Do I need to write a change log for each new version?
It is not universally required by repositories, but it is strong practice and is required by some funders’ and journals’ data-sharing policies. A short changelog (what changed, why, and how it affects prior results if at all) belongs in the dataset’s own description or an accompanying README, updated with every new version.
What happens to a paper’s citation if the dataset it cites gets a new version?
Nothing changes automatically. The paper’s citation and data-availability statement should reference the specific version DOI that was current when the analysis was run. If the version DOI was cited correctly, it continues to resolve to that exact data indefinitely, regardless of how many later versions are published.
Can I delete or replace a version instead of creating a new one?
Reputable repositories deliberately make this difficult or impossible for published records, precisely because it would break every existing citation. If a version was deposited in serious error (e.g., contains data that must be withdrawn for legal or ethical reasons), that is a retraction/tombstone situation to handle directly with the repository, not a routine versioning decision.
Does every repository support the concept DOI / version DOI split?
No. It is a feature of specific repository platforms (Zenodo and other InvenioRDM-based repositories are the clearest examples), not a universal DOI requirement. Before assuming it is available, check the documentation of the specific repository you are using — some repositories version datasets through revision metadata on a single DOI instead.
