Assign DOI to different releases and NUG

[cofinoa]

To report a non-security related issue, please provide:

• the version of the software with which you are encountering an issue
  Any
• environmental information (i.e. Operating System, compiler info, java version, python version, etc.)
  NA
• a description of the issue with the steps needed to reproduce it
  NA

I was improving and fixing the bibliography references at CF-Convention (cf-convention/cf-conventions#266) and in particular for Unidata's NUG, netCDF-C and UDUNITS.

For netCDF-C and UDUNIT I was using their corresponding DOI documented at Unidata's Aknowledgment.

For NUG @lesserwhirls has suggested to use the one created by @WardF.

Can be it possible to generated a new one DOI for the NUG?

The second suggestion it's to have different DOI, for different releases/versions with a top-level DOI?

Zenodo's provides this can of functionality:
https://guides.github.com/activities/citable-code/
and it can be linked to the Github releases process
https://blog.zenodo.org/2017/05/30/doi-versioning-launched/

I think it's something useful for citing code and their releases.

[WardF]

That's an excellent idea. When we finalize our initial release of the NUG, having a DOI assigned to it is a good idea.

[cofinoa]

@lesserwhirls thanks for moving to Unidata/netcdf repo. I wasn't aware of it.

My proposal it's also to make a DOI for each release of Unidata software. At least netcdf-c, tds, netcdf-java ....

[lesserwhirls]

As I see. This repo isn't quite "out in the wild yet", but the creating a DOI for the NUG part caught my eye and I wanted to make sure I didn't lose track of it.

@ddirks - two questions here related to DOIs:

1. Can we mint one for the NUG to have waiting in the wings for when it gets its first release?
2. Does our DOI minting service provide a versioning capability like Zenodo does?

[ddirks]

We can absolutely mint a DOI for the NUG, but it does need to have at least a temporary endpoint (URL) when we create it. If it's useful to create the DOI before the "real" release is ready, we can simply update the DOI when it's time to publish.

I think this is a great idea, and we should think about it in the context of documentation for all the various Unidata packages. The question of one DOI per release or one "umbrella" DOI that guides the user to the correct release bears some thinking about. On the software side, our scheme has been to maintain only one DOI for each package, letting the user choose the version they want. At the time this scheme was selected, the thought was that a proliferation of DOIs for disparate versions could lead to confusion -- because DOIs age gracefully, it's possible to find an old one and not realize it isn't current. (There are solutions for this, but they all involve ongoing maintenance.)

I don't believe DataCite (the DOI registration agency UCAR has a contract with) offers Github integration directly, but I'll dig into it. On the other hand, I believe Zenodo actually uses DataCite to register the DOIs. I don't know what the financial arrangements are. If we do want to generate version-specific DOIs, that's a very appealing workflow, and a prod for Unidata to regularize our use of Github releases.

[ethanrd]

The Zenodo FAQ explains how they do versioning:

How does DOI versioning work?
When you publish an upload on Zenodo for the first time, we register two DOIs:

• a DOI representing the specific version of your record.
• a DOI representing all of the versions of your record.

Afterwards, we register a DOI for every new version of your upload.

It is for uploads to Zenodo, not GitHub specifically, but I suspect it still applies.

[ethanrd]

Regarding DOIs through GitHub/Zenodo or direct with DataCite, we have discussed adding other non-NUG documentation in this repo at some point in the future. I'm not sure we could have DOIs for each documentation set going with GitHub/Zenodo DOIs.