Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rexT6-00EYF2-W8 for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Feb 2024 13:26:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rexT3-0031hM-Sr for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Feb 2024 13:25:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rexT3-0031hD-AL for pgsql-hackers@lists.postgresql.org; Tue, 27 Feb 2024 13:25:58 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rexSv-001V9t-PO for pgsql-hackers@lists.postgresql.org; Tue, 27 Feb 2024 13:25:56 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D4F0C5C0299; Tue, 27 Feb 2024 08:25:49 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 27 Feb 2024 08:25:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1709040349; x= 1709126749; bh=1uTKyK+003CXl8JDU6EUNVTHiCD5h8hlCIXo6nHoop0=; b=T yPKuaG42q3zFSZvkznzLBZpgpH8y5qRjOyRJvy6IMFUWA+hInjTVMXrnrexjBlFw IIut22ZWq8n5FX5UOnyhv18+h5WbXfWVWO3Fxoe5Tm5QUcZau+TL2GwE1hVyjT+t 1Qk/WoU1/0fVgTZ9u3TDrknD78LpGH/mrisMTADilJoKueTJ2VdivkWjBJqrfY8N AKAQ7iEqak5Ga3Vwprd5f36/CTFpphEoSxA8ee2CQMYUsQEseZeBTDOp8AvHns9z o2wsDiSCGXOPTWHU9y9It4AbjsOWqn9K1sSre0cuPMGxWsoPfb+/XIub2fM/VjAV F172nL6BBQC2+CGzG/0WA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrgeehgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedvkedtffduffdtffffheffhfejjefhgfeiueeukeejkeff gfdufffhudffffeuveenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 27 Feb 2024 08:25:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1709040346; bh=GWjkOWQ22K8t6tSlBU2u3xPP1rfjHzZiuqbDk0/+kRQ=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=iB7Yv90Ocszk4mxF6Rp260+Au6MiE5/npk5+1p59C3TDYHmceq6C/qoi/N+d5Qs55 i+hvDfxZkE09IPnUpxZGOZLABdjbtM/Gti0wwLrN74U2Nlq40CPeLrlXTGd9FOc1FX GoIG21qqOqcqIeUIRkNkQZ8Q8YhdA9NvfA05z0rZjCnYY/NGM48/MWLAXd611I37n0 iHdixdZwW1JfgEslZsePXKo2sG60xrj5jFTJbzqsePHWLZTp7zja069CVCaI9tCAcE eTG+PCR3N69g/BysraLvdf884xm8peRc4128ynMMEMgzJxISw+8220y3Ewjqw5MyQB muRGvtTHWYWIA== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 7E8611298; Tue, 27 Feb 2024 14:25:46 +0100 (CET) Date: Tue, 27 Feb 2024 14:25:46 +0100 From: Alvaro Herrera To: Peter Eisentraut Cc: PostgreSQL Hackers Subject: Re: abi-compliance-checker Message-ID: <202402271325.uclbq77mroza@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2023-Nov-01, Peter Eisentraut wrote: > v3-0001-abidw-option.patch > > This adds the abidw meson option, which produces the xml files with the ABI > description. With that, you can then implement a variety of workflows, such > as the abidiff proposed in the later patches, or something rigged up via CI, > or you can just build various versions locally and compare them. With this > patch, you get the files to compare built automatically and don't have to > remember to cover all the libraries or which options to use. > > I think this patch is mostly pretty straightforward and agreeable, subject > to technical review in detail. I like this idea and I think we should integrate it with the objective of it becoming the workhorse of ABI-stability testing. However, I do not think that the subsequent patches should be part of the tree at all; certainly not the produced .xml files in your 0004, as that would be far too unstable and would cause a lot of pointless churn. > TODO: documentation Yes, please. > TODO: Do we want a configure/make variant of this? Not needed IMO. The way I see this working, is that we set up a buildfarm animal [per architecture] that runs the new rules produced by the abidw option and stores the result locally, so that for stable branches it can turn red when an ABI-breaking change with the previous minor release of the same branch is introduced. There's no point on it ever turning red in the master branch, since we're obviously not concerned with ABI changes there. (Perhaps we do need 0003 as an easy mechanism to run the comparison, but I'm not sure to what extent that would be actually helpful.) -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/