semantic versioning how to

[funderburkjim]

Let's apply the semantic versioning for the new LRV dictionary.

I think I need to do something, but I don't know what!
@drdhaval2785 please advise.

[drdhaval2785]

Reference for update of semantic versioning - https://github.com/sanskrit-lexicon/csl-homepage/issues/9

Semantic versioning has three components MAJOR.MINOR.PATCH

MAJOR - Updated when there is a change which has no backwards compatibility e.g. python 3.0.0 was incompatible with python 2.7.6. MINOR - Updated when a new bunch of backwards compatible features were added. e.g. python 3.11.0 adds new features which are backwards compatible with python 3.10.8 PATCH - Updated for bug fixes or relatively small refactors or small utilities e.g. python 3.10.8 has some small change over python 3.10.7.

When MINOR is updated, PATCH is reset to 0. When MAJOR is updated, both MINOR and PATCH are reset to 0.

[drdhaval2785]

In Cologne we have something like 2.0.738.

When we add LRV, if is a backwards compatible change, and a significant change. Therefore, appropriate change would be to set the versioning to 2.1.0. Whatever corrections are being made thereafter would continue be numbered 2.1.1, 2.1.2 etc.

[drdhaval2785]

Currently we are using

2.0.git log | grep '^commit' | wc -l

It is a crude way of saying that the major and minor numbers are 2 and 0 respectively; and the patch number is the number of commits in csl-orig repository. This crude method served our purpose till now.

We may need to do two things.

1. change prefix to 2.1
2. If the number of commits in csl-orig is XXX as of today, we may need to change PATCH to be equal to “commits in csl-orig minus XXX”.

[gasyoun]

2.0.git log | grep '^commit' | wc -l

1.0 was pre-2022?

[drdhaval2785]

I am not sure, but I think that “1.0” was before we migrated to csl-orig i.e. git based version control of data.

[funderburkjim]

I think the major version number ('2') is to agree with the '2' in csl-pywork/v02.