From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 045551FF16B for ; Thu, 3 Apr 2025 12:50:57 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1D1B43D57C; Thu, 3 Apr 2025 12:50:45 +0200 (CEST) Message-ID: Date: Thu, 3 Apr 2025 12:50:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox Backup Server development discussion , Alexander Zeidler References: <20250328102242.75539-1-l.wagner@proxmox.com> <369cb438-f0bb-4d28-9db7-d6f45e76fd84@proxmox.com> Content-Language: de-AT, en-US From: Lukas Wagner In-Reply-To: <369cb438-f0bb-4d28-9db7-d6f45e76fd84@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.014 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] applied-series: [PATCH proxmox-backup v3 00/10] notifications: cleanup in preparation of overridable templates X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Backup Server development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On 2025-04-02 16:33, Thomas Lamprecht wrote: > 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. Yeah, I think the benchmark should be "all info is still there and readable" instead of "every byte of text must be exactly the same" - the notifications are primarily meant to be read by humans, after all :) > >> 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. Good point, I agree. Luckily I see the chances of us having to do incompatible changes to variables/helpers as rather small, at least after this round of cleanups for PBS/PVE. > > 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. -- - Lukas _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel