Change versioning

[kelle]

Consider changing version scheme from YYYY.n to N.yyyy.m, where N is the structure version and yyyy.m is for data updates. If the schema changes, we increase N. If we add more data, we increase m.

[kelle]

Also need to add a number for when the software (simple/utils) changes!

N - schema
X - software??
YYYY.m - data

N.X.YYYY.m?

Let's think on this.

[dr-rodriguez]

Discussing it further, I agree with N.X.YYYY.m

[kelle]

So, if we were to release today, it would be 1.1.2024.7.

[kelle]

another option, with lots of text: schema.1-simple.1-data.2024.7

[kelle]

or
1-1-2024.7
or
2024.7-1-1

We think schema should go first because it's the most breaking change.

[kelle]

waiting for #558 and pyproject.toml first.

[kelle]

Hm, maybe we don't want to use dashes: pypa/setuptools-scm#825

[kelle]

Due to the trouble with the dashes, we went with periods:
1.1.2024.7

[kelle]

Documented in https://github.com/SIMPLE-AstroDB/SIMPLE-db/wiki/Release-Workflow.

[kelle]

This page has a lot of useful info which would have helped this discussion: https://packaging.python.org/en/latest/specifications/version-specifiers/#version-specifiers. Reopening just to make sure we don't want to change our mind after reading.