At some point, we will publish pypromice releases to pip so we can easily install the latest pypromice package like so:
$ pip install pypromice
We can automatically publish pypromice as a pip package through a GitHub Action that publishes new releases (see here for the walkthrough and here for GitHub Action documentation). Once published, we cannot change the version naming convention of the pypromice pip distributions.
Therefore, our version name conventions need to be defined before we move forward. At the moment, our pypromice releases on GitHub are mismatched with our Dataverse versioning (found here: https://doi.org/10.22008/FK2/IPOHT5). This is because Dataverse versioning is fixed to single digit naming conventions V1, V2, V3.... For example, the most recent pypromice release on GitHub is v0.0.1, however on Dataverse the same release is called V1. This presents ambiguity.
I propose that we coordinate pypromice versions across GitHub, pip and Dataverse, whereby all three platforms have the same major versions v1, v2, v3..., but only GitHub and pip host sub-releases v1.1.0, v1.2.0, v1.3.0...
Major releases should be published when pypromice has significant changes that alter PROMICE one-boom and/or two-boom dataset releases
Sub-releases should be published when pypromice has changes to improve usability, efficiency, structuring etc., but do not significantly affect PROMICE one-boom and two-boom processing and datasets
If anyone has any alternative ideas or additional input then it would be appreciated. I would like to have this sorted before submission to JOSS (manuscript draft can be found in the joss-paper branch here)
At some point, we will publish pypromice releases to pip so we can easily install the latest pypromice package like so:
$ pip install pypromiceWe can automatically publish pypromice as a pip package through a GitHub Action that publishes new releases (see here for the walkthrough and here for GitHub Action documentation). Once published, we cannot change the version naming convention of the pypromice pip distributions.
Therefore, our version name conventions need to be defined before we move forward. At the moment, our pypromice releases on GitHub are mismatched with our Dataverse versioning (found here: https://doi.org/10.22008/FK2/IPOHT5). This is because Dataverse versioning is fixed to single digit naming conventions
V1, V2, V3.... For example, the most recent pypromice release on GitHub isv0.0.1, however on Dataverse the same release is calledV1. This presents ambiguity.I propose that we coordinate pypromice versions across GitHub, pip and Dataverse, whereby all three platforms have the same major versions
v1, v2, v3..., but only GitHub and pip host sub-releasesv1.1.0, v1.2.0, v1.3.0...If anyone has any alternative ideas or additional input then it would be appreciated. I would like to have this sorted before submission to JOSS (manuscript draft can be found in the joss-paper branch here)