Version change

[PennyHow]

Because we are releasing a new Dataverse AWS dataset, I think the pypromice version needs to move up also (as we will also publish pypromice to Dataverse again).

I explained in #79 that keeping consistent version naming conventions between Github, pip and Dataverse is tricky.

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

So, if we go with this, then pypromice will be V2 when we publish it to Dataverse alongside the AWS data release. And therefore the new release on Github (in setup.py) needs to also be v2.0.0.

[PennyHow]

I really like the idea of keeping pypromice alongside the Dataverse AWS data entries, but I see that it just does not fit with semantic versioning (which I really think we should do, and what we have begun adopting (ish) in the pypromice releases here). We may have to move away from pypromice being on the Dataverse altogether to avoid the clashing versions then.

We already cite the version of pypromice being used on the AWS data releases, so we can keep doing as we are in this respect.

So the question is, what should this current version be? I think we have had some pretty major updates, so maybe v1.0.0?

[patrickjwright]

@PennyHow It seems strange to roll out a v2.0.0 version for pypromice for such a new package, when the previous version was v0.0.1. And I do really think we should try to stick to semantic versioning with pypromice as much as possible (in agreement with you there).

I like the idea of synching the Dataverse pypromice version with the major pip/GH version, if it is sustainable...

The only issue I see is that people might use the Dataverse version of the files (which could be quite old and lacking many updates, if we only change the dataverse version with major releases).... but why would anyone use the actual files on Dataverse?? Seems like anyone actually using the package would go through Github to fork, or pip to install, etc. In which case, the Dataverse version is just there to have citability and a DOI? And we may as well line up the major version number...

But then there is the problem that if we want to start right now keeping the Dataverse version consistent with major pypromice versions, then yes we have to start with v2.0.0.

Perhaps Dataverse is inappropriate for software, and should really only have data...

If Dataverse weren't a part of this at all, then yeah, we could probably just start at v1.0.0. I don't really know what controls the changeover to v1 (Pandas went forever with v0.x.x versions, and was perfectly functional software!). But, pypromice seems somewhat mature and stable, and is very much used in a production capacity, so I am good with v1.0.0.

I guess we just need to decide if any attempt should be made to synch with Dataverse version. Could we remove the current Dataverse entry and start with a new v1 to align with pypromice==1.0.0?

[PennyHow]

Version specified in setup.py is now v1.0.0.