search

ropensci / RNeXML

Implementing semantically rich NeXML I/O in R
https://docs.ropensci.org/RNeXML
Other
13 stars 9 forks source link

Archive copy of repo on Zenodo #96

Closed cboettig closed 8 years ago

cboettig commented 9 years ago
rvosa commented 9 years ago

Zenodo copies need to be tagged releases, so "latest version" does not apply precisely.

On Tue, Nov 4, 2014 at 7:31 PM, Carl Boettiger notifications@github.com wrote:

  • Make sure that Zenodo copy syncs to latest version
  • Update package CITATION file/function appropriately.

— Reply to this email directly or view it on GitHub https://github.com/ropensci/RNeXML/issues/96.

cboettig commented 9 years ago

@rvosa yeah that's what I meant to write anyway. Our tags correspond to versions 'released' to CRAN, so the Zenodo archive should correspond 1:1 with the version history as CRAN sees it.

Note we have semantic version numbering; with the additional practice (borrowed from RStudio folks) of appending .99 to the active development version (so we can distinguish if someone has installed from Github vs CRAN). Hence we're on version 1.1.3 on CRAN and 1.1.3.99 on Github, which will be bumped to 1.1.4 on our next CRAN release (assuming it's bug fixes and not new functionality).

hlapp commented 9 years ago

@cboettig did you do this before or as part of submission?

cboettig commented 9 years ago

@hlapp Good question, I could use some feedback here.

I first set up the Zenodo tracking on Nov 5th, but as I had not yet tagged a release, nothing was pushed to Zenodo yet. However, on Dec 6th I pushed a new version of RNeXML to CRAN (2.0.0), which implemented a simple change in the user-facing functions/API of the package (making the nexml argument to add_basic_meta be the last instead of the first argument, for consistency with all other methods. Since this change could potentially break existing code, we bumped the version up).

I've been tagging CRAN releases in git corresponding to their version, so when this release was tagged it was published to Zenodo. Since then we had a minor change (2.0.1) requested by CRAN on 2014-12-26 (see NEWS), but the Zenodo API was failing over the the holiday, and this tag was not detected (I understand the issue has since been fixed).

The more recent tweaks for the manuscript+vignettes will be in release 2.0.2, but CRAN requests packages do not submit updates more frequently than every two months; so this has not been pushed to CRAN. Consequently the Zenodo version is still at the 2014-12-06 version (2.0.0), CRAN is as 2.0.1, and Github at 2.0.1.99 (which will be bumped to 2.0.2 when pushed to CRAN and then bring everything to the same version).

So, long story short, perhaps it's not great having the manuscript in the same repo as the R package, since it makes it harder to keep these synchronized? (On the other hand, there's a certain advantage to having everything together).

To address this, perhaps we want to have tagged releases on Github that correspond to versions of the manuscript, independent of tagged releases that correspond to versions released to CRAN? This still leaves the question of how to structure the manuscript-related tags. I suppose this could be done according to submissions; e.g. submitted-mee-1 or something like that? Or is it likely too confusing to have both software version tags and manuscript tags in the same repo?

hlapp commented 9 years ago

I guess it depends on what is the primary goal for having an archive of record on Zenodo. If it's the software reported in the paper, rather than the manuscript, then changes to the manuscript that do not change the code should not trigger re-archival in Zenodo. Also, if the version on CRAN is what we are reporting in the manuscript (and I think it is, isn't it), then the archive on record associated with the paper should be consistent with that. Which it seems it is at present.

The one thing that's amiss is that the DOI of the archive at Zenodo is not referenced in the text, which made me think that there is no archive. We should make sure that we cite the DOI in the revised version (assuming that the text won't be accepted straight up as is). This would then also serve as the DOI for the data used in the paper, for which in the submitted version we don't cite an archival record either. (Hint hint for a reviewer who is wondering what to criticize :smile: )

cboettig commented 9 years ago

+1 regarding referencing the DOI in the text. As the DOIs are versioned too, there's also the matter of which DOI to use. (At present, I think Zenodo could do a better job of connecting multiple versions)

For me, the Zenodo archive exists simply to provide a (DatCite) DOI for and 'permanent copy' of the Github repository (along with more machine-readable metadata served through OAI-PMH and also indexed & served by DataCite). The Github repository exists to provide the full version-ed record of both the software and the paper, and having them in the same repo makes sense to me as they are both manifestations of the same 'project'. I suppose I could be convinced that they should still be separate repos on Github, and thus separate archives on Zenodo.

hlapp commented 9 years ago

I wasn't trying to make a case for separating repos for software and manuscript (AFAIAC, I'm mostly neutral on that question). I was just trying to argue what should take priority in triggering a new Zenodo deposit, and according to my argument it seems the version of the software that should have been deposited for this initial submission of the manuscript is indeed deposited. (It's just not cited in the paper.) It also seems that putting a new version on CRAN triggers a re-deposit on Zenodo, which sounds to me what we want to have for the purposes of citing in the paper.

hlapp commented 8 years ago

The v2.0.0 release was archived in Zenodo, which is referenced in the paper: DOI

There are newer v2.0.x tags since then, which haven't been made into point releases yet, but that's I think separate from this issue.