[pbs-devel] applied-series: [PATCH proxmox-backup v3 00/10] notifications: cleanup in preparation of overridable templates

[Thomas Lamprecht]

Am 02.04.25 um 15:27 schrieb Lukas Wagner:
> I would suggest:
>   - no backward-incompatible changes in minor upgrades
>   - for breaking changes in major upgrades, implement some best-effort 
>     checks in pbsXtoY/pveXtoY which check any custom templates for
>     anything that will be changed/removed
> 
> 
> Incompatible changes are:
>   - removing variables
>   - changing type/representation of variables (e.g. switching from number of bytes to KiB, etc.)
>   - removing helpers
>   - non-trivial changes to a helper's behavior
>   - incompatible changes to the rendering engine (e.g. switching from Handlebars to something else)
> 
> Backward-compatible changes would be:
>   - adding new template variables
>   - adding new template helpers
>   - adding new, optional parameters to existing helpers
>   - trivial changes to helpers (hypothetical example: "1KiB" -> "1 KiB" for `{{ human-bytes 1024 }}`)

The last one is really something where the "no breakage" means
"no report from users", but I'm fine with that with smaller adaptions.
 
> What do you think?

Sounds about right.

I'd probably also mention that we try to do changes by adding them as new
variable/helper/... if the resulting maintenance burden is somewhat
manageable, as with that we can then have co-existing old/new for a while
(e.g., the current major release) and drop the old one in the next major
release, which would simplify major upgrades combined with sharing templates
be it through pmxcfs or some configuration management stack the admin uses,
like Ansible, compared to rolling out such changes in one go with a major
upgrade.

This does not change what you state above w.r.t. what counts as breaking
change and is not so much relevant for the consumers of that info (those
overriding templates) but can be nice to state the general guideline for
devs to roll out such changes there nonetheless.