arfon
commented
3 years ago :wave: @matthewfeickert, thanks for opening this. I agree versioning is important and I would be useful to have this available in the paper.
For the motivated reader, the version is tracked on the JOSS review thread (see below), although I see from your review this caused some confusion.
I think it would be relatively straightforward for the paper to simply capture and display the string (Version: v0.12.3 in the case of the paper you link to) on the paper and not having done this to date is somewhat of an oversight on our part.
If there is agreement by the journal Editorial Board that this would be useful though, I would be willing to work on a PR to add this if a core developer could give me guidance.
Great! I'd be happy to work with you on this change 😸
matthewfeickert
JOSS already does a great job of including lots of important metadata related to the software and the review in the metadata of the paper (here I'm mostly thinking of the metadata that is printed on the left hand side of the first page of the paper). c.f. screen grab from the most recently published JOSS paper (as of 2021-01-30)
However, this metadata doesn't include the version release of the software reviewed, which seems (to me) to be a very important piece of information. Why I agree that at first it would seem that this is rendered irrelevant by the fact that the repository URL and Zenodo archive URL are part of the paper metadata, this came up as a pain point in the review for
pyhfin https://github.com/openjournals/joss-reviews/issues/2823, where having the release version number explicitly stated in thepapermetadata would have cleared up some confusion (at least I think that would have helped). e.g. having under the Software metadata a "version: v0.5.4". (This isn't directly related, but Issue #442 also touches on how "version" numbers are important to the review.)I realize that this could be slightly problematic as the concept of versioning isn't universal (e.g. SemVar and CalVar both exist) but if the recommended way to install the software is from a package index (e.g. PyPI, Conda-forge, CRAN) then the version number matters quite a bit to a user of software published in the journal then what they're going to find at the HEAD of the default branch of GitHub/GitLab.
I appreciate that the journal Editorial Board put a great deal of thought into the metadata of the paper and that I'm probably not the first person to bring this up, so I apologize if I'm missing an obvious reason for the lack of version number. I'm also not intending this as a criticism of the journal or the board. If there is agreement by the journal Editorial Board that this would be useful though, I would be willing to work on a PR to add this if a core developer could give me guidance.