Enforce versioning guideline by CI checks

[leogr]

Motivation

Currently, the versioning guidelines need to be manually checked and applied by maintainers, which is an error-prone process.

Also, see my comment here.

cc @falcosecurity/falco-maintainers

Feature

Enforce versioning guidelines using the CI.

One possible solution would be to automatically add a label indicating the type of change (major, minor, patch) to incoming PRs. In this way, it will be immediately clear to the release manager which version number must be bumped when git tagging.

Alternatives

Additional context

Off-topic
A similar approach could be used in libs too since we have a similar problem with internal version numbers (ie. DRIVER_VERSION and SCHEMA_VERSION)
cc @falcosecurity/libs-maintainers

[jasondellaluce]

The label-based approach seems interesting. Another way could be to introduce a custom release note syntax (like we use to do for Falco).

The approach that I would prefer the most would be for Falco to "dump" (in a machine-readable format) all the definitions loaded in a given rules file and being able to apply all/most of the versioning guidelines automatically. This also matches the request of issues such as falcosecurity/falco#1814, which still want Falco to dump its rules internal knowledge for ease of debugging and development. Just an idea, maybe not attainable, but would be cool.

[mstemm]

How will this version relate to the required_engine_version? I would think it would be appealing to have the major number be equal to the required_engine_version but that doesn't quite line up with the versioning guidelines doc.

I guess one way they would be related is that any time the required_engine_version is changed, the major number also has to be incremented. But the versioning guidelines doc talks about changes in the minor number related to required engine version changes, so that isn't consistent.

Also, what will happen when loading multiple rules files, like default and local files? There isn't any attempt to relate those version numbers, is there?

[leogr]

/kind feature
/milestone falco-rules-0.2

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[jasondellaluce]

This is now accomplished.

/close

[poiana]

@jasondellaluce: Closing this issue.

In response to this:

This is now accomplished.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.