Mailing List Archive

On Tue, Dec 5, 2023 at 8:47?PM Nils Goroll <nils.goroll@uplex.de> wrote:
>
>
> commit 5583667fedcb969d112b17fdb4d84f2e910e75fe
> Author: Nils Goroll <nils.goroll@uplex.de>
> Date: Tue Dec 5 21:44:49 2023 +0100
>
> VRT minor version bump for #4013
>
> we need a signal if the fix is in

Have you considered running a VTC at configure time instead?

> diff --git a/include/vrt.h b/include/vrt.h
> index 26509f344..b378920a2 100644
> --- a/include/vrt.h
> +++ b/include/vrt.h
> @@ -48,7 +48,7 @@
>
> #define VRT_MAJOR_VERSION 18U
>
> -#define VRT_MINOR_VERSION 0U
> +#define VRT_MINOR_VERSION 1U
>
> /***********************************************************************
> * Major and minor VRT API versions.
> _______________________________________________
> varnish-commit mailing list
> varnish-commit@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-commit
_______________________________________________
varnish-commit mailing list
varnish-commit@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-commit

On 05.12.23 23:32, Dridi Boukelmoune wrote:
> Have you considered running a VTC at configure time instead?

No, in my mind, this is what the VRT version is for ("bump minor number for new
functionality") and it is much simpler to use on the consumer side.

Do you have a different opinion?

Nils

--

Nils Goroll (he/him)

** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753

xmpp://slink@jabber.int.uplex.de/

http://uplex.de/

_______________________________________________
varnish-commit mailing list
varnish-commit@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-commit

On Wed, Dec 6, 2023 at 5:34?PM Nils Goroll <nils.goroll@uplex.de> wrote:
>
> On 05.12.23 23:32, Dridi Boukelmoune wrote:
> > Have you considered running a VTC at configure time instead?
>
> No, in my mind, this is what the VRT version is for ("bump minor number for new
> functionality") and it is much simpler to use on the consumer side.
>
> Do you have a different opinion?

As a matter of fact, I do.

VRT is minor-bumped for additive changes to the not-clearly-defined VRT ABI.

--->8---
$ git log varnish-7.4.0..master -- include/vrt*.h bin/varnishd/cache/cache.h
commit 5583667fedcb969d112b17fdb4d84f2e910e75fe
Author: Nils Goroll <nils.goroll@uplex.de>
Date: Tue Dec 5 21:44:49 2023 +0100

VRT minor version bump for #4013

we need a signal if the fix is in

commit 4d584ddb082c1b343f70eb467578814f29f75033
Author: Nils Goroll <nils.goroll@uplex.de>
Date: Wed Oct 18 12:08:14 2023 +0200

Start NEXT sections in vrt.h and changes.rst

to anchor patches
---8<---

There hasn't been an ABI change registered since the last bump.

Cheers,
Dridi
_______________________________________________
varnish-commit mailing list
varnish-commit@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-commit

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?

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"?

Nils


--

Nils Goroll (he/him)

** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753

xmpp://slink@jabber.int.uplex.de/

http://uplex.de/

_______________________________________________
varnish-commit mailing list
varnish-commit@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-commit

On Thu, Dec 7, 2023 at 10:02?AM Nils Goroll <nils.goroll@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
_______________________________________________
varnish-commit mailing list
varnish-commit@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-commit