Versioning strategies for Coraza

[jptosso]

We use golang's semantic versioning, for example:

v2.4.12-beta.3:

• Major: 2
• Minor: 4
• Patch 12
• Non-stable release: Beta 4

API breaking changes require a new major version

API Changes cannot break regression, if we require to break an existing API we can deprecate and create a new one or create a new major release.

Minor release

We only create minor releases when there is a new non api-breaking feature or we remove something.

Major Release rolling alternatives

Feature based

Whenever a feature that is considered core or awesome is required to break compatibility we release a major version. It could easily lead to 3 major versions per year.

Anual based

We release one major version that would break compatibility per year (or some other period)

To be continued

[jptosso]

We agreed on feature-based releases. See #180