First release + release protocol

[jwokaty]

No description provided.

[sdgamboa]

@jwokaty, I think this should be similar to bugsigdb. Are these the steps involved:

1. Create a release (GH)?
2. Create a Zenodo repo with that reease.
3. Add Zenodo.json?

[jwokaty]

Are the exports in the correct format? And we are including the .gmt and .csv files? Is this for version v1.0.0?

I want to make sure everything is correct before we put it on Zenodo because when we make it public, we can't change it later; we would have to make a new versioned release.

I will set this up but I would like confirmation on the above questions before we do the release and add the files to Zenodo.

[jwokaty]

For the release, I should

• Make zenodo.json
• Make prerelease
• Evaluate/test prerelease

Let's use this issue to document the process for a release.

@sdgamboa What tests can could be used to evaluate the data for correctness? I could possibly add them to the GitHub Action.

[sdgamboa]

I added a quick test that makes sure that all GMT files are created and can be imported into R: https://github.com/waldronlab/bugphyzzExports/blob/main/tests/testthat/test-gmt_files.R

I was thinking about adding one for csv files as well, just to check that the csv files are complete, all columns are present, and they have the right class.

I was thinking of making this repo a package and moving the export files (csv, GMT, and log) to inst/extadata. Would it be possible to only release the files in extadata on Zenodo instead of all of the repo? @jwokaty, what do you think?

[sdgamboa]

I think another helpful test would be to make sure that Taxon_name GMT files are indeed character strings and NCBI_ID GMT files are integers.

[jwokaty]

If we want to put the csv, log, and gmt files in inst/extdata, I'd need to change the GitHub actions workflow to place them there. For the releases, the files should be manually added to the release, which isn't hard to do. (We might be able to automatically generate the releases with the files in that path with an action like https://github.com/marketplace/actions/create-release, but I haven't tried it yet.)

I think it's good to have tests on the data. I know the data for bugphyzz may not change as much as BugSigDB, but I was able to easily catch some issues before the release because there were good tests.

Is there a test from bugphyzz that should be run to assess if the data is good when importing data from bugphyzzExports?

[jwokaty]

Noting that I made waldronlab/bugphyzz#240 to import from different resources.

[sdgamboa]

I felt the data was ready for a first release.