Versioning strategy

[kslong]

in the past, we have used a scheme that if transferred directly to Sirocco would be something like sirocco01a for the executable. This had the advantage that it was easy to create a series of versions that one could check against one another, and this was a feature that I used often for regression tests. I would like to have something that permits me to operate in a similar fashion, but it is unclear what the plan is.

I think there is a feeling that we need more discipline/formal in versioning going forward, which is what the new versioning scheme is trying to do. In this scheme, you would have major and minor releases, but probably not want to make use of this for incremenal testing.

I would appreciate it if @jhmatthews would fully outline what he has in mind to satisfy both the advantage of a more formal version scheme, but to enable incremental development along the way.

I also have a couple of smaller questions:

• What is the version we expect to use for the paper, 1.0?
• Is the naming convention for sirrocco, e.g sirocco-0.1 intended. The other programs, e.g windsave2table do not have a dash. It seems like we should be consistent.

[kslong]

Ultimately whatever the version strategy is, it should be added to Sphinx

[jhmatthews]

Quick thoughts:

• My intention was to "approximately" follow semantic versioning: https://semver.org/ ...
• ...but, I don't know if we/I have enough discipline - or backwards compatibility, given how the windsave file works - to really stick to their versioning strategy, but I was at least thinking the MAJOR.MINOR thing might work in a broad sense similarly to how we used 88b and so on.
• I don't particularly mind whether we have a dash, I just felt like quite a few other programs do and it made the text a bit easier to read when there's a 0

I think this means you should be able to use things similarly to before with regression, or you can compiled with VERSION which is what I sometimes do. E.g., if I'm testing a patch I might run

make VERSION=0.1-matom-patch sirocco

or use the first 6 characters of the commit hash, e.g.

make VERSION=0.1-43a5d0 sirocco

Commit hash is the most robust way to do it, but a bit cumbersome perhaps. Could figure out how to automatically also create that version.

[jhmatthews]

Just a note that if we want to change it would be good to do it now so I can modify the release string for the arxiv submission.

[kslong]

The commit hash approach certainly does not work for me, as the chronology is not obvious, which works with our old abc approach. How about 0.1a, 0.1b, etc, with the intention when we go to 0.2 that whoever merges into main makes that change. And when we do go from 0.1 to 0.2 or whatever, we add a tag every time. This would leave some intermediate commits with different versions.

... or I guess if I standard compiled with VERSION=whatever, then I could do anything I wanted.

[jhmatthews]

We can do that, or full 0.1.1 semver style. Either is fine with me I guess. Probably the main thing is just that we merge into main more often and always have a version like 0.1 or 0.2 whenever we do that.