To make different versions of the same software (or component) findable, each version needs to be assigned a different identifier. The relationship between versions is embodied in the associated metadata.
Domain-agnostic comments
What is considered a “version” is defined by the owner of the software: in many cases this will be something that the owner wants to specifically identify and use and/or “release” or “publish” so that others can use and reference/cite. This is something for which there may be disciplinary norms, which may be documented in domain-specific software guidelines e.g. ESIP Software Guidelines in the earth sciences and CESSDA Software Development Guidelines in the social sciences.
Identifiers for each software version should be globally unique and persistent (as tested by FRSM-01) and use the same identifier scheme. It may be useful to reference these identifiers in any release documentation or CHANGELOG.
F1: Software is assigned a globally unique and persistent identifier.
F1.2: Different versions of the software are assigned distinct identifiers.
R3: Software meets domain-relevant community standards.
Possible Implementation
domain-agnostic
requirements
Software Identifiers
method
Check if each software identifier resolves to a different version and examine identifier metadata.
essential
Each version of the software has a different identifier.
important
Relations between the versions are included in the identifier metadata.
useful
The version number is included in the identifier metadata.
Check that each release follows CESSDA software publication policies and is deposited in a repository that provides a unique DOI for each release.
essential
Each release is published to Zenodo and a DOI obtained. A publication consists of a release tarball matching the release tag in the repository. Release tags exist and adhere to SemVer 2.0.0. The README and CHANGELOG must be up to date prior to release and they must be added to the Zenodo record in addition to the tarball.
important
A release checklist is used to ensure that all necessary steps are taken for each release. Releases must be available as Docker images with the release version as tag.
useful
Reserve the DOI in Zenodo, prior to release, to avoid a circularity problem with the CHANGELOG and the tarball.
karacolada
commented
1 month ago
D5.2, p13 + p24
Detailed Description
To make different versions of the same software (or component) findable, each version needs to be assigned a different identifier. The relationship between versions is embodied in the associated metadata.
Domain-agnostic comments
What is considered a “version” is defined by the owner of the software: in many cases this will be something that the owner wants to specifically identify and use and/or “release” or “publish” so that others can use and reference/cite. This is something for which there may be disciplinary norms, which may be documented in domain-specific software guidelines e.g. ESIP Software Guidelines in the earth sciences and CESSDA Software Development Guidelines in the social sciences.
Identifiers for each software version should be globally unique and persistent (as tested by FRSM-01) and use the same identifier scheme. It may be useful to reference these identifiers in any release documentation or CHANGELOG.
CESSDA comments
These are derived from the CESSDA Software Publication policy and procedures for open source components, as set out in the CESSDA Publication Policy & Procedures (CESSDA, 2020).
Context
F1: Software is assigned a globally unique and persistent identifier. F1.2: Different versions of the software are assigned distinct identifiers. R3: Software meets domain-relevant community standards.
Possible Implementation
domain-agnostic
CESSDA