From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Iterative Tinkering depends on API stability Date: Wed, 15 May 2024 14:41:31 +0300 Message-ID: <861q63uwt0.fsf@gnu.org> References: <871q63tz8j.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19862"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: "Dr. Arne Babenhauserheide" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 15 13:42:45 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s7D1x-0004wo-C4 for ged-emacs-devel@m.gmane-mx.org; Wed, 15 May 2024 13:42:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s7D1C-000100-0y; Wed, 15 May 2024 07:41:58 -0400 Original-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 1s7D14-0000zg-2g for emacs-devel@gnu.org; Wed, 15 May 2024 07:41:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s7D12-0003Qw-OM; Wed, 15 May 2024 07:41:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=s/7APxLSgdyGGWw4goqlNERjoQXWV4SEkxISAZpIIiA=; b=EoyiN3SwzM+gckg+WTew +JJ2eFLBcdfHxhpoOEdGUNG4Q1YtFkpZf8YpESjQpRrZA2T+jAEv4eycJ8lhBq8sYH1URB7vtPRw8 sId0/ZdyTnmokxxERubRLOB7uzrbCxu+KB+ThKdXpHOd3oMCjFjBOVS90pJNDy4ITux+6jIRLBKyV qX4IhJJQoJuBysevoOBTHucrzBY4l26KRYc9djsZlmZSBmPvK/+B/gumdBFYhQsbaKO74KbUvRJcj 0rHgt5FvjoNEBSTZ0IO+e2yRmrHbk1K98O3LyqJY7jxZCazX/Xkr/i5fVb/MQA+WQse56lJ+QcRhw hzEm3Syh7pe7+A==; In-Reply-To: <871q63tz8j.fsf@web.de> (arne_bab@web.de) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319251 Archived-At: > From: "Dr. Arne Babenhauserheide" > Date: Wed, 15 May 2024 07:34:20 +0200 > > So I want to plead to remember the risk of volatile software¹, volatile > infrastructure², and soft trauma³, when taking decisions about backwards > compatibility. > Breaking backwards compatibility has much wider-ranging implications > than it seems while working on code, and it hits the most most > advanced specialist tooling and the most enthusiastic tinkerers the > worst. I think you are preaching to the choir here. Breaking backward compatibility is something we try to avoid like the proverbial plague, every single day. The example you mention, with mu4e, is not necessarily relevant to this list, since mu4e is not part of Emacs; you should bring that problem to the attention of the mu4e developers.