versioning: add versioning framework for the syslog-ng 4.0 transition (4.0)

[bazsi]

The plan to release syslog-ng 4.0 would be as follows:

• we are accumulating changes destined for 4.0 by merging them into
  subsequent syslog-ng 3.x releases, but working in a compatible mode so
  that no changes would be visible to 3.x users.

• Usually we report changes to behavior using warnings at
  startup and we do this release-by-release. With 4.0, we expect a broader
  set of changes that we would like to present to users as a whole. For
  this reason we will suppress these warnings for changes we plan for
  4.0 at least until the user explicitly indicates interest in the
  experimental features.

• the user can start using the new features as follows:

  • by using @Version: 3.255 in a config, the warnings about changes get
    enabled (while continuing to work in 3.x compatibility mode)

  • by using @Version: 4.0 in a config, the changes are enabled and
    syslog-ng would start working in the new mode we plan for 4.0.

  • in a way all new features/changes would operate behind a feature flip,
    which the user can control using the @Version line in a
    configuration.

• the features provided by the 4.0 mode are experimental and this mode is
  not intended for production use.

• once the 4.0 features/changes are all baked, we release syslog-ng 4.0,
  which would make the new features/behaviours official. The v3.255 mode
  of operation would be disabled and the feature flip removed. Essentially
  the only change would be that upgrade warnings would always get enabled.

Signed-off-by: Balazs Scheidler bazsi77@gmail.com

[kira-syslogng]

Build SUCCESS

[bazsi]

The dbld images fail to build as "dwarves" (a tool I use in devshell from time to time) has become missing from debian-testing. It should resurface tomorrow, so I am not removing it from the build manifest.

[kira-syslogng]

Build SUCCESS

[MrAnno]

An example of how the 4.0-versioning API can be used:

https://github.com/syslog-ng/syslog-ng/blob/77ace16b4a2976905c933909a4c46de087083522/modules/json/format-json.c#L86-L101

[kira-syslogng]

Build SUCCESS

[MrAnno]

(Just for the record: I approved the PR to indicate that I like the idea of how we'd like to transition into v4. We're still discussing the details and its internal implications.)

Needs re-review

[bazsi]

I have now implemented version number based feature flips. I would appreciate help in checking if this would work your internal builds of PE.

Also, if version_from_user() is not used in versioning.h, can we eliminate that indirection? Also, a lot of defines in versioning.h is not actually used in the codebase, I'd probably eliminate that too.

[MrAnno]

Thanks, @bazsi.

I'll check the internal parts by Friday.

[kira-syslogng]

Build SUCCESS

[MrAnno]

@bazsi I think I got a bit confused at the "OSE handover" discussion, the current versioning PR makes it possible to map internal versions, for example:
https://gist.github.com/MrAnno/26bf5e3ee626790c6834dbcb0dfabc2e

It seems a bit overcomplicated because we need to redefine what VERSION_VALUE_4_0 and VERSION_VALUE_3_LAST mean anyway (making next_major a bit unnecessary), but it works in my opinion. I'll test it in practice tomorrow.

[bazsi]

@bazsi I think I got a bit confused at the "OSE handover" discussion, the current versioning PR makes it possible to map internal versions, for example: https://gist.github.com/MrAnno/26bf5e3ee626790c6834dbcb0dfabc2e

It seems a bit overcomplicated because we need to redefine what VERSION_VALUE_4_0 and VERSION_VALUE_3_LAST mean anyway (making next_major a bit unnecessary), but it works in my opinion. I'll test it in practice tomorrow.

I convinced myself to simplify things a bit, so we won't need VERSION_VALUE_3_LAST and use the (flip_over_version - 1). With that you will only need to redefine VERSION_VALUE_4_0 and and FEATURE_TYPING_MIN_VERSION both to 0x0800

[kira-syslogng]

Build SUCCESS

[MrAnno]

Thank you.

We'll test the current version of this PR internally with your other 4.0 branches.
Once it's done (hopefully at the beginning of next week), I'll reapprove the PR and move forward with the review of the other PRs that depend on this one.

Until then, could you help with the review of opened PRs, please? There are 32 opened pull request, 12 of them is related to the 4.0 changes, which I'm trying to focus on, but it is still a lot. :)

[MrAnno]

Internal tests: apart from the above minor things, everything else seems to be OK.

[bazsi]

I've resolved all comments with an update to the branch.

[kira-syslogng]

Build SUCCESS

[MrAnno]

👍🏻

@bazsi Thank you very much for doing this in a way that helps our internal builds.