Use commit SHA

[maelle]

Related to #132

When writing codemeta.json for a package with a remote etc, should the latest commit SHA be acknowledged somewhere? As sameAs for instance?

[cboettig]

Yeah, this is a great question and definitely related to #132 . Both are example of the chicken-and-egg problem discussed in codemeta/codemeta#167

For instance, it's impossible for a file to report it's own SHA, so it could be at best one commit behind.

As you point out in #132, it's easy to end up with the DOI being 'one behind', i.e. pointing to the last 'release' of the software. As described in codemeta/codemeta#167
, with DOIs it is possible to 'pre-register' a DOI (one of the advantages of using an 'opaque' identifier that contains no information about the object it is describing), which is the "correct" way to do a release: pre-register, update the codemeta.json @id with the DOI, then launch the release. Unfortunately, Zenodo pre-registration isn't part of the GitHub integration with Zenodo, and so has to be done 'manually' (i.e. with @karthik's upcoming zenodo package). Ideally, Zenodo would just automatically pre-register your next DOI and display it in the Web UI as soon as your release was created by the GitHub release; which would solve the issue.

There is an alternate but bad solution of using Zenodo's generic DOI, which always resolves the "latest" version. This might sounds like a good idea but it isn't, since a codemeta file always describes a particular version (i.e. it even states the version in version), and this would mean the identifier quickly becomes inaccurate. Permanent identifiers are not supposed to change targets! (In principle you could sidestep this issue by having a separate notion "all versions of a software project", vs "a version of a software project", but no current schema that I know of supports this concept; all we have is the concept of softwareSourceCode, which almost always implicitly means "a particular version of the softwareSourceCode" and not "a collection of versions". Note that anything that points to a moving target like "latest" should never be used as an identifier, but rather only as a relatedLink etc. (Guess that goes for CRAN canonical URLs too... should fix!).

[maelle]

Thanks!

Guess that goes for CRAN canonical URLs too... should fix!

I've thought about that too, but there's no URL for CRAN by version right?

[cboettig]

Only for archived versions I think... Might be good to ask Kurt about this.

[maelle]

Indeed great if you can ask ☺

[cboettig]

email sent