Allow explicit calendar versioning and provide actionable rules for version semantics

[sthagen]

PR #46 nicely made the version concept actionable.

But, it leaves producers employing calendar versioning in a more explicit way outside in the rain.

I suggest to modify the version type value regex to allow calendar versioning variants that hint explicitely at that semantic:

^(0|[1-9][0-9]*)(\\.([0-9]+)){0,3}$

that way a version like 21.04 Is valid - which would help producers that have set up their software development to use calendar versioning (because intrinsic semantic versioning just did not work well for them) - the results are still orderable in any packaging relevant context.

Regardless of this proposed change:

Can we help the ecosystem / communities by distilling actionable rules as guidance from the members working in the field which classes of changes would be expected to impact which degree of change indicator?

Given the tight coupling between the advisories and the expected reaction upon receipt, I imagine we should be able to help here - if it is only informative it will still help to foster communication between producers and consumers. Even better, when we can normatively state a SHOULD with confidence.

[tschmidtb51]

I would refrain from introducing calendar versioning since we already a field date in the revision_history. Moreover, it would leave to consumer alone not knowing whether the rules from semantic versioning apply or the issuer wanted to use calendar versioning in this document. It might be easy to guess for 21.04 that this is probably a calendar versioning string, but what about 10.12? This is also a valid semantic versioning string.

Therefore, I suggest to offer 2 versioning systems:

• semantic versioning (as the preferred one, with the rules we provide)
• integer version (just increment the number for each new final version)

A document must not mix both versions. Draft versions before the initial release should have a version string starting with 0.. There should only be final or interim versions in the revision_history when the document is released.

[tschmidtb51]

I added PR #233 as a suggestion. It is still in draft status (so that it doesn't get merged accidentally) and does not implement the changes in the JSON schema yet. I'm interested whether this is the way to go. If the answer is yes, I'm happy to make the changes to the schema and fix the examples.

[sthagen]

I will take a look at the proposed wording in the new PR. If we can come up with clear and actionable rules that relate an advisory over the full life span to a semantic version, there is no need for using a calendar version.

But, if we cannot provide that regime and producers start to just fake semantics on the version field for formal validity, ...

The tricky part for me is not assuming producers do not care, or us as anTC not being capable of formulating that relation into an indicator (version), but that in my experience a minor for the producer is a major for the consumer 😉

[sthagen]

I did take a look and as noted in my review summary of #233 we may close this issue upon merge of that PR #233

[tschmidtb51]

This is fully solved in Editor revision 2021-05-21.