Find a releases workflow

[Jomula]

Things we should release regularly:

• JSON Schema
• Frontend Sourcecode
• Data?

[theodore-s-beers]

Is it definite that we need to version and publish releases for the frontend? It seems to me that it's more important for the schema and project data—i.e., the stuff that lives in the main branch of the repo.

Any time that we create a release pointing to the latest commit, it will have an archive of all the source code as an attachment. Creating a new release for each update to the schema—and being fastidious about versioning the schema—would be a good starting point.

[Jomula]

How about this:

• Standard Release: The whole project (=main branch) is going to be released regularly via the github/zenodo automation, the DOI is for generally linking to the project
• Schema Release: The schema is released separatly on zenodo without the automation to github, as soon as there are changes, we can include the DOI in the readme and/or even in the schema itself.
• Data release: The data is to be released separatly on zenodo as a dataset without the automation to github, as soon as there are changes. The DOI can be included in the readme, if someone wants to refer only to the dataset.

This means that someone has to do the releases on zenodo regularly (can also be split, schema is your responsibility @theodore-s-beers, data is yours @XeniaMonika), but I think this is the best option to avoid the issue that all releases of the repository are regarded as being one thing in zenodo. What do you think @theodore-s-beers ?

[XeniaMonika]

I also think it shouldn´t be released altogether, since the data changes more rapidly than the schema. I can take care of data releases. Should I release it anytime the dataset changes? We make small changes very often, so I´m not sure if I should make a release every single time I edit something or only after big changes, like adding a new project. Or maybe a better approach would be to do it in regular time intervals, like once a month. What would you suggest?

[Jomula]

@XeniaMonika Zenodo releases are pretty easy, once you created a release you can just upload newer versions as a zip file and add a version. We should maybe discuss the difference between minor changes, patches and versions and then do releases for every patch? minor? major? What does @theodore-s-beers think?

As for the standard release I'd suggest regular schedule, like once a month as minor, patches if there is a major change in workflows and version if we have major changes in the frontend or structure.

[theodore-s-beers]

The schema and the overall repository/dataset are already versioned separately, so each can and should have its own release schedule.

I think the schema version should be bumped whenever changes are made—or at the end of a "round of changes," to avoid excessive churn. We can talk more about how to observe semver. I don't have strong opinions on that.

For the repository/dataset, I agree that a fixed interval is better. But I think quarterly releases would make more sense than monthly, based on the rate at which our records are growing and changing.

The "standard release" and the "data release" should probably be done on the same schedule, i.e., quarterly in my opinion.

Let me know what you think. It seems we are close to a consensus.

[Jomula]

Ok, so suggestion would be:

• Repository release: Done via Github/Zenodo-Implementation every quarter
• Data release: Done manually via Zenodo every quarter, or when new projects are added
• Schema release: Done manually via Zenodo when schema is changed

EDIT: I just did a quarterly general release to have something that is up to date: https://zenodo.org/record/8367363
As for Data and Schema, you'd need to register at Zenodo and create a release manually. For new releases you can simply do that on the records page on zenodo when you are logged in.