OCSF Versioning Scheme

[jp-harvey]

Working under the assumption that semantic versioning should be adopted, either same as or along the lines of those specified at https://semver.org/...

What versioning scheme should we adopt?

1. Sequence Based

1.0.0
1.0.0rc1
2.2.0dev4

Used everywhere, clear on where API changes happen, but not clear just by looking at the versions when they were released.

2. Date Based Short

Examples

22.7.0
22.7.0rc1
22.10.dev4

Immediately obvious when the release happened, but the concept of MAJOR no longer means "breaking API changes", so more than one release with a breaking API change in a calendar year is not compatible.

3. Date Based Long

2022.7.0
2022.7.0rc1
2022.10.0dev4

Same as option 2 but even more obvious it's a date.

[rroupski]

1. Sequence Based (and we should use '-' to separate the version from the build)

1.0.0
1.0.0-rc1
2.2.0-dev4

[jsantoyo-splunk]

How about a combination for option 1.

1.0.2208

Adding the YYMM at the end to cover the "when" the version was released.

[rroupski]

I'd like to keep it simple. Why does any needs to know (just by looking the release version) when the schema was released? How does it help? And I hope, we don't have to make many releases...

[jp-harvey]

Having the date in the version is convenient to see when something was released, and the combo of date and semantic is used in creative ways in other projects. For this project there's not a great deal of benefit that I can see and KISS is probably preferable.

wrt to using the - that's another discussion after this one, I don't have particularly strong feelings. I used the Python scheme in the example since that's what I'm most accustomed to, but the - is used by other notable languages / package managers like NPM so it's not like we'd be doing something weird.

[pagbabian-splunk]

I had added the major and minor sequence explanation in the white paper: major changes can be breaking, minor changes cannot. Minor changes reserved for addition to the schema (new core classes, attributes, etc.). The patch sequence was for fixes that are not breaking, such as description or caption updates. Can anyone think of other examples?

Also, extensions do not impact the core schema version, but must follow the same approach. Where would an extension's version be populated though? The core schema is ignorant of extensions and shouldn't represent them.

[jp-harvey]

Pro tip: ctrl-F does not find words in PDFs in Github unless you go to raw view. At least we pretty much all agree on this one!