Currently people submit an archive of their software but we don't capture what version (i.e. v1.9.0 or SHA) of the software people are submitting. Should we?
I think this ties in to how we handle versions in general. We have to decide on something like the following:
1) paper and DOI are for one specific version and it should be specified with submission. With new major releases a completely new paper should be prepared with a completely new DOI.
2) There is one main DOI_v1 for the paper referring to the original submission but the paper can be versioned also. So a new major release would get paper_v2 and DOI_v2. Perhaps if 10 citations exist for DOI_v1 and 10 for DOI_v2 a system can keep track of this to report 20 citations to the software project as a whole.
I'm in favour of option 2. I like that if feasible it helps collect overall number of citations as well as allowing accurate citing of a particular version.
Currently people submit an archive of their software but we don't capture what version (i.e. v1.9.0 or SHA) of the software people are submitting. Should we?
IMO, it has to be part of some standard metadata (or perhaps in the yml of paper.md).
Re: A paper for each version, It would be terrible noisy if package authors did that. It would also create a citation mess (People in my world often cite the wrong versions all the time). Unless the software does something entirely different, we wont need another paper. If we step back a bit, the authors are providing a high level functionality of their software, along with a few research applications. We are not capturing change log level detail.
I think we should capture version numbers. See https://danielskatzblog.wordpress.com/2016/04/17/to-better-understand-research-communication-we-need-a-groid-group-object-identifier/ for some discussion. Also, in the software citation working group workshop this morning, we talked about 3 types of software identifiers: 1 - ID of a specific version, 2 - ID of all versions, 3 - ID to latest version.
I'm also partial to this:
2) There is one main DOI_v1 for the paper referring to the original submission but the paper can be versioned also. So a new major release would get paper_v2 and DOI_v2. Perhaps if 10 citations exist for DOI_v1 and 10 for DOI_v2 a system can keep track of this to report 20 citations to the software project as a whole.
It's similar to zenodo's github integration, which issues new versions & captures release name (which I believe is linked to SHA).
Yay @acabunoc in JOSS!
@danielskatz said:
I think we should capture version numbers.
I think I agree with this. So my question is, can we simply ask the author to specify the version of the software in the submission form and then perhaps ask the reviewer to check that there is a corresponding GitHub release?
@Kevin-Mattheus-Moerman - I like your ideas about versions and in future iterations of this I'd love to work out how to allow for (re)submissions that are for new major releases.
maybe we want to make sure there is a DOI for the released code at that version, either in Zenodo or figshare currently, but other places that support this would also be welcome.
Most helpful comment
Yay @acabunoc in JOSS!