From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id uKMQB1kWrGV0JwEAqHPOHw:P1 (envelope-from ) for ; Sat, 20 Jan 2024 19:52:09 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id uKMQB1kWrGV0JwEAqHPOHw (envelope-from ) for ; Sat, 20 Jan 2024 19:52:09 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=jGL49dAb; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1705776728; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=9gRW4HpVPLha1pAQit5GkutEIrdhaAvd2p2Wzjv7Mg4=; b=LXeaa2sRvjxcv2J8RkvAR1BAgu0kzeEMezNk1+QPykmpxKCUDmLtSWPEvaPn5uhag4zdv9 GAEnLkhqEXm4oWLPprkC73PtJNLIjkuBJLgdi7dlBe5WdcMiydUpKR0UtFCaV/0DAB+DVA x3yWDM0c519AfoQYUQtnohi8E3mDTTOLJOOPnQQnAoOk31SLZG2aCHZlF3jiBVJqT3p87N vqkXfenWReH3FWJ/Q0bnCoswuNxEL3i9/qYQC6vVUAsYKPzDzE6Yul87Bx+JkPwk/61oyo FYNt9i/owPgOpMCxrCcejbatFBZH7AB+nxrhDG6QJwWZ5ALoKSvkQy+8tU7/dw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=jGL49dAb; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1705776728; a=rsa-sha256; cv=none; b=cYYx696B4b/eR0GgaFXmTAomdVykWLFfQ6MDsMOQHEVVyorRjPpvKkUVPdJFhxngoBqW4H vsvFwh1Bb9kj7QldKXCyFJr9iS1glJH7hO5Y+uQgVcoydLcBc1J8mXKKG/a3GLb3FnM4mA /R5dwG3z0ucENvVpviVlrMl/IZvArxPgLPhSr6hn6/ySjYE3gPeyuGcAPLKZrKjwujrcqk rTPzOufq8nrYAu1hYFOAxBd4gH3597NLuAZzC1mwyO8OqGEl127JuXbAc9KaFemic3SsFA nPWKYsO5Pj4J5LOxH+y2hCQQW+Od/kpP6Dky4zsIyyKZUH4yLi1JKXzS6f0M0Q== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id BF5343969D for ; Sat, 20 Jan 2024 19:52:08 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rRGQx-0000BH-NT; Sat, 20 Jan 2024 13:51:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rRGQv-0000B1-Em for emacs-orgmode@gnu.org; Sat, 20 Jan 2024 13:51:09 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rRGQs-0001K6-59 for emacs-orgmode@gnu.org; Sat, 20 Jan 2024 13:51:09 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 95C91240101 for ; Sat, 20 Jan 2024 19:51:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1705776662; bh=MktaAhsjAAHQTMewGDFa5Serd72RWWUdRWm+8BQQCqM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=jGL49dAbray2BYBP5VFobBKg79zKSRmS7zuRplho7BIMA1RIT7jyfmJOYW1t1Aplz De6b6gWe6awhphVocAeNChI0UnewpGgT9US5zFgg0mmGfKzeaoIBMikODU6azrQV0n Z55O2vpR0cK18VjFMlRyObG+Iwod0iEbhClSPlNC9tbuc0bDMwnup0qYiuFzpTSI6x SoAdMV/B/P45cz38vS2ZUtwzyKWuIs7laUPS+3ZF87TIUiY+eHtQZZZH3EG1cRI8vG fHu0zQ+BvASbmtdiaQ16ZSAgr0Ve7GcFMYZfp7f6ZCuANU7ey48OWllPRVfsg1OZ1w gFql2JjqcK7aw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4THQYL037Zz6tvZ; Sat, 20 Jan 2024 19:51:01 +0100 (CET) From: Ihor Radchenko To: Matt Cc: emacs-orgmode Subject: Re: Backwards compatibility (was: Re: [PATCH] ob-shell: consistent prefix) In-Reply-To: <18d279c9696.11f7c699f365957.5930695120108631730@excalamus.com> References: <18d279c9696.11f7c699f365957.5930695120108631730@excalamus.com> Date: Sat, 20 Jan 2024 18:54:19 +0000 Message-ID: <8734ur6dk4.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -8.74 X-Migadu-Scanner: mx13.migadu.com X-Spam-Score: -8.74 X-Migadu-Queue-Id: BF5343969D X-TUID: Gzb9ulDLVYvo Matt writes: > How far does backwards compatibility extend with regard to Org itself? > For the next version, for all time, or something else? Usually, until next major release (we should have major releases more frequently in future). However, we often keep compat code in place even much later if it does not stay on the way of maintenance or implementing new features. > The rule I infer from your comment is, "renamed symbols must be > aliased." This implies that any arguments associated with the symbol > are the same after the name change. How do we handle changes in > function APIs? I'm thinking of something like > =org-babel-execute:shell= and =org-babel-sh-evaluate= where it would > make sense to refactor the =stdin= and =cmdline= parameters. 1. When we need to add new arguments, we usually add them as optional arguments at the end. 2. When we need to remove arguments, we just keep the relevant arglist names as _ (indicating that the argument is unused). 3. When API is changing more significantly, we obsolete the old function code and keep it in org-compat. Then, we implement a completely new function with a new name, and use it throughout Org mode. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at