Define versioning

[pellared]

What would be the use case to bump the "patch number"?

I am used to have "patch" when versioning the config files. Usually it is only "major" or "major.minor" depending on how strict is the parser.

Originally posted by @pellared in #13 (comment)

[jack-berg]

My initial instinct was to include only major and minor. Given that patch is reserved for backwards compatible bug fixes, the patch version should never be relevant to a configuration file.

[pellared]

My initial thought was the same. However, I am not sure if supporting minor would not be unnecessary complex.

Let me illustrate it by example

1. The application supports scheme version 1.3
2. The config file states that it uses scheme version 1.1
3. The config file uses settings that are introduced in 1.2 and 1.4

How should the application react when parsing such file?

Should it see the settings introduced 1.2 and 1.4 as errors as they were not defined back then? To implement it we would need a very strict parsing...

Should the application "fail fast" or log warnings and gracefully ignore the setting(s)?

I feel that just sticking with scheme-version: $MAJOR would be good enough and remove a lot of complexity.

[codeboten]

I'd expect minor versions to be used for any additive changes to the configuration, and major bumps only required when backwards incompatible changes occurred. For an application that supported 1.3, i would expect it to ignore any configuration options specified in 1.4 and support everything coming before 1.3, which would include 1.2.

As for name, i agree that we should be more specific, i don't want to bike shed too much on this. I think schema-version would make sense, but we should decide if we support camel, snake, or kebab (unsure if that's the correct name for hyphen separated casing) casing.