[master] 5583667fe VRT minor version bump for #4013

[Dridi Boukelmoune]

On Thu, Dec 7, 2023 at 10:02 AM Nils Goroll <nils.goroll at uplex.de> wrote:
>
> Yes, I probably should add a comment to vrt.h regarding the vbf_objiterate() change.
>
> On 07.12.23 10:00, Dridi Boukelmoune wrote:
> > VRT is minor-bumped for additive changes to the not-clearly-defined VRT ABI.
>
> I agree to not-clearly-defined. Is the stevedore API part of the VRT ABI?
> Directly or indirectly?

The stevedore API is exposed in cache_varnishd.h and is clearly not $VRT abi.

> Regarding "additive changes", I read
>
>   * Whenever something is deleted or changed in a way which is not
>   * binary/load-time compatible, increment MAJOR version
>
> as applicable for an incompatible change.
>
>
> Overall, which harm is caused by a minor bump given that we practive unnecessary
> major bumps for releases "to be on the safe side"?

Another reason for major bumps "safety" is also that we branch out. If
trunk major-bumps to 18.0 when we release 7.4, and we minor-bump
trunk, then if in the future we need to minor-bump 7.4 after a
security release for example, then we have two competing 18.1 VRT
versions.

I have suggested in the past to add namespaces to VRT so we could have
something like this:

- varnish-cache-trunk 18.0
- varnish-cache-7.4 18.0
- varnish-cache-6.0 7.1
- varnish-enterprise-6.0 7.5

On top of the current X.Y rule we could add an exact match requirement
for the namespace, to make sure that a VMOD built for a given ABI
could not load on a different one that happens to share the same VRT
version. This way, we can drop the "just to be safe" attitude we have
today and start bumping trunk only when relevant.

In this specific case, that's irrelevant since this is not a VRT change.

Dridi