From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Lukas Wagner <l.wagner@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>,
Alexander Zeidler <a.zeidler@proxmox.com>
Subject: Re: [pbs-devel] applied-series: [PATCH proxmox-backup v3 00/10] notifications: cleanup in preparation of overridable templates
Date: Wed, 2 Apr 2025 16:33:44 +0200 [thread overview]
Message-ID: <369cb438-f0bb-4d28-9db7-d6f45e76fd84@proxmox.com> (raw)
In-Reply-To: <b747eae5-0a10-4219-b32e-9ac692443be6@proxmox.com>
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.
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
next prev parent reply other threads:[~2025-04-02 14:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-28 10:22 [pbs-devel] " Lukas Wagner
2025-03-28 10:22 ` [pbs-devel] [PATCH proxmox-backup v3 01/10] notifications: move make notifications module a dir-style module Lukas Wagner
2025-03-28 10:22 ` [pbs-devel] [PATCH proxmox-backup v3 02/10] notifications: add type for GC notification template data Lukas Wagner
2025-03-28 10:22 ` [pbs-devel] [PATCH proxmox-backup v3 03/10] notifications: add type for ACME " Lukas Wagner
2025-03-28 10:22 ` [pbs-devel] [PATCH proxmox-backup v3 04/10] notifications: add type for APT " Lukas Wagner
2025-03-28 10:22 ` [pbs-devel] [PATCH proxmox-backup v3 05/10] notifications: add type for prune " Lukas Wagner
2025-03-28 10:22 ` [pbs-devel] [PATCH proxmox-backup v3 06/10] notifications: add type for sync " Lukas Wagner
2025-03-28 10:22 ` [pbs-devel] [PATCH proxmox-backup v3 07/10] notifications: add type for tape backup " Lukas Wagner
2025-03-28 10:22 ` [pbs-devel] [PATCH proxmox-backup v3 08/10] notifications: add type for tape load " Lukas Wagner
2025-03-28 10:22 ` [pbs-devel] [PATCH proxmox-backup v3 09/10] notifications: add type for verify " Lukas Wagner
2025-03-28 10:22 ` [pbs-devel] [PATCH proxmox-backup v3 10/10] notifications: remove HTML template for test notification Lukas Wagner
2025-04-02 12:45 ` [pbs-devel] applied-series: [PATCH proxmox-backup v3 00/10] notifications: cleanup in preparation of overridable templates Thomas Lamprecht
2025-04-02 13:27 ` Lukas Wagner
2025-04-02 14:33 ` Thomas Lamprecht [this message]
2025-04-03 10:50 ` Lukas Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=369cb438-f0bb-4d28-9db7-d6f45e76fd84@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=a.zeidler@proxmox.com \
--cc=l.wagner@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal