I really like the approach laid out by @castelao. A few points are probably worth mentioning/stressing:
#### DOIs for Versions This is baked into Zenodo. If you have a look at [the Zenodo FAQ, Section "DOI versioning"](https://urldefense.us/v3/__https://help.zenodo.org/__;!!G2kpM7uM-TzIFchu!k7QrDTweHMm38Kl-4lU9brbOfgYfr6W3iz4sEbjTYU1eS5jRwy0lf9zZBdpgIddHC5clW9-2SJU$ ) you will find more information, but the most salient quote is perhaps: > When you publish an upload on Zenodo for the first time, we register two DOIs: > - DOI representing the specific version of your record. > - DOI representing all of the versions of your record. > > Afterwards, we register a DOI for every new version of your upload. So using Zenodo, it is almost unavoidable to give a new DOI to every version. Of course we could discourage the use of individual version DOIs or use a different service than Zenodo, but the similarity of the schemes is no accident, but rather follows from the idea of referring to an immutable thing with one DOI. #### Zenodo contents and Github integration It is true that the standard Github integration places an archived version of the Github repository into Zenodo. However, this is by no means the only way to do it. We could, for example, archive only the PDF version of the conventions in Zenodo, together with a link to the relevant release/tag on Github, or only the HTML version or both. This is also possible in an automated way with no manual overhead. #### Zenodo landing page As far as I understand it is also true that Zenodo *always* uses the Zenodo landing page, so if we would like to have a different landing page, for example the CF conventions website, a different service must be used. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/127*issuecomment-934213961__;Iw!!G2kpM7uM-TzIFchu!k7QrDTweHMm38Kl-4lU9brbOfgYfr6W3iz4sEbjTYU1eS5jRwy0lf9zZBdpgIddHC5clWXnzPLk$ This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
