[Feature]: [FRSM-03] Does each version of the software have a unique identifier?

[karacolada]

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

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.

CESSDA

requirements	Repository release tag, Software release identifier
method	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]

Skeleton evaluator:

fuji/fuji_server/evaluators/fair_evaluator_version_identifier.py

Line 10 in 1778e73

class FAIREvaluatorVersionIdentifier(FAIREvaluator):