Suggestion: Option to Preserve/Reassign File DOI Across File Replacements

Overview of the Suggestion
When a file is replaced in Dataverse, the replacement is treated as a brand new file object with a new file ID and a new DOI. There is currently no way to preserve or reassign the original DOI so that it resolves to the latest version of the file. This issue proposes a mechanism — likely an API endpoint and/or a UI option — to support this use case.

For example, on this demo dataset: https://demo.dataverse.org/dataset.xhtml?persistentId=doi:10.70122/FK2/3HB6JK

Original file transactions.csv → DOI: doi:10.70122/FK2/3HB6JK/LRMNET
Replaced file transactions.csv → DOI: doi:10.70122/FK2/3HB6JK/KMOB3W

The two files are linked in Dataverse's replacement chain metadata, but their DOIs are independent with no "latest version" DOI resolving to the most current file.

What kind of user is the suggestion intended for?
(Example users roles: API User, Curator, Depositor, Guest, Superuser, Sysadmin)
Depositor, Curator, API User

What inspired this idea?
A discussion about the behavior of file-level DOIs when files are replaced in collections with file DOIs enabled. Depositors who regularly update a file (e.g., a living dataset in .csv or .tsv format) find that each replacement mints a new DOI, making it difficult to maintain a stable, citable reference to the latest version of that file. There are good arguments for both concepts:

1. A DOI should only ever point to a specific file with specific contents. When a file is replace with a new one, a new DOI should be minted in order to maintain the conceptual differences between two files. Users should cite the specific DOI for the specific version of a file.
2. Maintaining a stable DOI across versions aligns with how dataset DOIs are handled in Dataverse. The DOI is registering the Dataverse object/landing page, not the file itself; there are other identifiers to do that: fileId and (arguably) a file hash. Users cite the file in a more complete way with both the DOI and the version number.

Other repositories handle DOIs in varying ways: Zenodo handles versioned vs. concept DOIs at the record level, where one DOI always resolves to the latest version and another resolves to a specific version, and ICPSR assigns new DOIs, with suffixes for specific versions.

What existing behavior do you want changed?
No change to the default behavior is strictly required. The current behavior (a fixed DOI per file object that reliably resolves to the exact file for which it was registered) is valid and likely expected by some users. Any new behavior should be opt-in so as not to break existing workflows or citations.

Any brand new behavior do you want to add to Dataverse?
Several approaches were discussed and are worth evaluating:

Option A: API endpoint to reassign an existing file DOI to its replacement. When file N has been replaced by file M:

1. Remove the DOI from the dvobject for file N
2. Register that DOI as an AlternativePersistentIdentifier on file M
3. No re-registration with the DOI provider is required — since the DOI already resolves via citation?persistentId=, the AlternativePersistentIdentifier entry handles routing correctly

Dataverse already tracks the replacement chain in metadata and already supports AlternativePersistentIdentifier.

Option B: UI checkbox on the file replacement page. Present the user with a choice at the time of replacement. Reassign the existing file DOI to this replacement file (so the old DOI resolves to the new file going forward), or keep the default: mint a new DOI for the replacement file (current behavior)

Option C: Add an additional DOI, Zenodo style. One type is fixed (the md5 doesn't change, if it were a file) and the other is not.

Any open or closed issues related to this suggestion?

Are you thinking about creating a pull request for this issue?
Help is always welcome, is this idea something you or your organization plan to implement?

Nope! Filing to gather community input and discussion on the topic.

No files, tests, or entry points are named. Start by tracing Dataverse’s file replacement flow, DOI assignment, and AlternativePersistentIdentifier handling, then inspect the relevant API and replacement UI paths. Done requires a defined opt-in behavior and community agreement on how stable and version-specific file identifiers should work.