first draft of licensing and archiving chapters#107
Conversation
|
|
||
| Platforms like GitHub, GitLab, Codeberg allow you to make your code findable and accesssible to the public. However, these platforms do not function as long-term archives - there is no guarantee these platforms will still be around in 10 years. | ||
|
|
||
| Archiving your code involves creating a snapshot (in other words, a frozen copy) of your repository at a given point in time and uploading that to an archiving platform such as Zenodo. This process makes your code persistent and citable, particularly because a persistent identifier (PID) will be issued to your code. |
There was a problem hiding this comment.
I would go also into the details when to do what.
Something like:
A stable release is a version of software that is considered reliable and ready for general use. It has been tested, major bugs have been fixed, and no major changes are expected that would break existing functionality.
In software development, a stable release is typically the version that users, researchers, or collaborators should use, as opposed to experimental or development versions.
You create a stable release when the software has reached a reliable milestone but may still continue to evolve.
You archive a release when you want to preserve a version permanently.
Typical situations:
- A paper or report is published
The exact code used in the study should be preserved and citable. - The project is finished or inactive
Archiving ensures the code remains accessible even if development stops. - Reproducibility is required
Other researchers must be able to retrieve the exact version used. - Compliance with research policies
Some journals or funders require software to be archived with a DOI.
Below we show how to archive and publish a release with Zenodo.
|
|
||
| Don't forget to commit and push your updates to the CITATION.cff file! | ||
|
|
||
| #### GitHub Releases |
There was a problem hiding this comment.
Move up before walking through the flow
|
|
||
| A GitHub Release is a snapshot of your code that you will create at specific points in your repository's development. | ||
|
|
||
| ##### Tagging Releases |
chStaiger
left a comment
chStaiger
left a comment
There was a problem hiding this comment.
Thank you very much for writing out the new chapters.
I think the licensing is ok like that. We are not really experts and linking to the license selectors is the most important thing here.
I would sort the archiving and publishing part differently.
One can create several releases before finally going through the Zenodo workflow. So I would separate those two. I left some suggestion how to phrase and structure it below.
3 participants
Hellohello! I've drafted some text for the licensing and archiving chapters.
The text for licensing is pretty limited at the moment, let me me know if there should be more text to elaborate on the concepts.
The text for archiving is a little messy, but all the necessary concepts are covered. I'm not sure how you teach the workflow these days, I started off with enabling the GitHub x Zenodo integration and then going back to GitHub to work on the CITATION.cff files and making a release. Then you go back to Zenodo and hopefully see the release pop up. I would rather not have to switch between GitHub & Zenodo, but it seems better than making a release twice?
I put more information about CITATION.cff files, Semantic Versioning & Calendar Versioning, GitHub Releases. There are no screenshots at the moment, I would like to finalize the text and flow first. The same goes for links and references.
I can update the slides when we have a direction on the text.