From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 5E6831FF168 for ; Tue, 12 Nov 2024 15:07:19 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 90A2D2AF0E; Tue, 12 Nov 2024 15:07:18 +0100 (CET) Date: Tue, 12 Nov 2024 15:06:45 +0100 From: Christoph Heiss To: Thomas Lamprecht Message-ID: References: <20241112131815.670475-2-c.heiss@proxmox.com> <05e00eda-7161-4c4a-8a89-5c73517a3c81@proxmox.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <05e00eda-7161-4c4a-8a89-5c73517a3c81@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.030 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: [pve-devel] [PATCH installer] post-hook: add `$version` field describing document schema version X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Cc: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On Tue, Nov 12, 2024 at 02:44:48PM +0100, Thomas Lamprecht wrote: > Am 12.11.24 um 14:18 schrieb Christoph Heiss: > > [..] > > --- a/proxmox-post-hook/src/main.rs > > +++ b/proxmox-post-hook/src/main.rs > > @@ -133,6 +133,17 @@ struct CpuInfo { > > #[derive(Serialize)] > > #[serde(rename_all = "kebab-case")] > > struct PostHookInfo { > > + /// major.minor version describing the schema version of this document, in a semanticy-version > > + /// way. > > + /// > > + /// major: Incremented for incompatible/breaking API changes, e.g. removing an existing > > + /// field. > > + /// minor: Incremented when adding functionality in a backwards-compatible matter, e.g. > > + /// adding a new field. > > + // This field is prefixed by `$` on purpose, to indicate that it is document metadata and not > > + // part of the actual content itself. (E.g. JSON Schema uses a similar naming scheme) > > + #[serde(rename = "$version")] > > maybe still use $format-version or $hook-version or the like for the > serialized key? I.e., to even better convey that this is, e.g., not some > version from the installer or product. What do you think about "$hook": { "version": "1.0" }` maybe, thereby making it a bit more structured from the start? Esp. when thinking about future expansions, if we ever want to add additional metadata fields. As we're already on the topic of future changes. But no hard feelings, otherwise I'd just go with `$hook-version`. > > Albeit a hook-version would be probably sent along as HTTP header, as > that then would even bigger change, but as a) it's rather unlikely that > we change away from JSON and b) the absence of such a header can be used > as v0, it is probably overkill now. Also, sending as HTTP header would most likely complicate implementing a server somewhat, depending on the tool/framework used. IOW, having it in the document directly is quite useful IMO. But it's a nice idea for the future to have, if we ever need something like this. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel