From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 8BgSFw539WUA2QAAqHPOHw:P1 (envelope-from ) for ; Sat, 16 Mar 2024 11:40:14 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 8BgSFw539WUA2QAAqHPOHw (envelope-from ) for ; Sat, 16 Mar 2024 11:40:14 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kPS5dHik; 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=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1710585614; 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=9AX8FsMWNVcVbvrscUQZes/9vTX3c4WfeRjWhejL/JA=; b=fXX30UkElAdzZbf+xri0ZsCP/9LPLWVHPXxlQ/Vkq1YSOTDpAttxztN2lS5PGM2BaUfujk gRxMMwH9cLYe75o+soVi0WGFSUEHrQUKn6yi4+uU4SV5HySLwON5Tqn0l4JZn7LlKN1YF0 zuINHqQirYbz2VXyI9SbtQmwbksHIRVvDfjz1U9uk6P1WOrdRJ1pMpskloQ3i6rfvmKovB rQzS8dAzQAAXXx9iFS5u58wGR+4Vx4XRqR6Vzw/ossiYTarv9ShJBxGidG+7Oa8pUVfR2D Qk37J8fS2rEDc2s0nUP1ql3DvpYiOzgVs8CLM7uhDCHay+YLRfmzkNg34JGoWA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kPS5dHik; 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=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1710585614; a=rsa-sha256; cv=none; b=mHwbdx1EIKriEISiiVkcPgjqw4YRSKPZEu56TjzpWTbBXj4jWhHudidOE9XPTUPXVLZKA5 hhdQ0nfneqqpLV62l6mI5xHnykrwkjOcSMSM0c7WPmhwEyHt7JK5uor3dcCoMghQ/FVVPC VFW9EwpxwVrdT8vpm5zBA5pnuJaykmzIGSpoW/G+Xe3rg+NxhWLQYTbd3j1ItDrfMFZa4r asoSqiGb8zx9y3q9Ay0Iz8M1nlwRxXJba4Eo8miJr3s8Ay1BrBN/6LotxFvGFUkcDiShhS r9SBrGaG31UX080Tljqp+7pj1cPus40tj1pnAd5nwCJYY7SovloVZT/bcofYlQ== 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 1D311631E5 for ; Sat, 16 Mar 2024 11:40:14 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rlRRy-0002wz-6J; Sat, 16 Mar 2024 06:39:38 -0400 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 1rlRRx-0002wo-1c for emacs-orgmode@gnu.org; Sat, 16 Mar 2024 06:39:37 -0400 Received: from mail-oa1-x33.google.com ([2001:4860:4864:20::33]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rlRRv-0002zh-42 for emacs-orgmode@gnu.org; Sat, 16 Mar 2024 06:39:36 -0400 Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-2220a389390so1517192fac.0 for ; Sat, 16 Mar 2024 03:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710585574; x=1711190374; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9AX8FsMWNVcVbvrscUQZes/9vTX3c4WfeRjWhejL/JA=; b=kPS5dHikv3BAp0cBN69XlBb9MF4ALJnPtiKWDs0TMQSmYSH7fcR18pzFCinIYphmze Xul+e93fGWAf5FsJnhxnlQnmcl7ANWFPOcgN9IynvGZ3JSBb6fwCR9UdZsKI3YmuZY79 asr9GuHbUXoVNytGJRAGyaR2oiltrFawOv2h7aQisPkD0+xWkPFTZm7QpFBQ8ebxRjRt wvf1ur2+jxUpJmMKcUcpAaDbGKqG9OMPh4j3GbCr3qNlGaclL2ejXaofcfBFfjkh2w7d XLGqpt2gdoLqMdoioO/56O/EfsYTwNJ1GBq2zNbUWeMDrmtcQGO/Ho3YZQuGPCFw+vhN HwXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710585574; x=1711190374; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9AX8FsMWNVcVbvrscUQZes/9vTX3c4WfeRjWhejL/JA=; b=q7E1U8SdI4f0c0ytZ61xp3BVwt7dB2444AmQd+wSgzsmd6MtvmPJF/2sQ5qGwnHPd4 icPlk6zYJhaQG7f9Jy/mteR6fKusCaJNZFcHiM/ACd8rxV/Ekk5vFLMeF4S+COq6lVos VSvJH0aEGJcD7KufVscmbuIGyZXTUAqXMQXiHjsZWu0zWco3N0NZKVqrGUWWXMLUexLO Jy9iGkBIg3CgmAXW1xj8VPoznXAIp7KjkCpmi1IIMnbFexhHkycznL+8prXWDn9hk0sS jJuV+jXD+ijMKf7qC8zB4AryrxaPJzDeHyNQwnSsxmDgVDhMyHp8YGvx3gfPaGFcSb/7 fBcw== X-Gm-Message-State: AOJu0YyYCHb8besDAuIW2CXpDSjQy11Xmpz/vyb4VIvxp0pEu5/PSpvN o/Nx2ZSF5RDBr1mQQmuQcBbST9fFFLBwV2LtdI3BpuGwi2Y7alIRljgVVMncK/ABwL6NkCfysmA p/TXrOF6z+0tHKOTderZYq2R5zfzw/ihYKSRczQ== X-Google-Smtp-Source: AGHT+IFB8flaKqAwiMK/KrU0MZ5x7VmsKsx71A4sXvBdlKuHY8uYVjzsT0IxSiXIXc69bSxAgEod3Q4oQiJJQfjzVgQ= X-Received: by 2002:a05:6870:8e16:b0:221:96eb:65 with SMTP id lw22-20020a0568708e1600b0022196eb0065mr4248583oab.7.1710585573755; Sat, 16 Mar 2024 03:39:33 -0700 (PDT) MIME-Version: 1.0 References: <87plvuiiov.fsf@localhost> In-Reply-To: <87plvuiiov.fsf@localhost> From: Rudi C Date: Sat, 16 Mar 2024 14:08:57 +0330 Message-ID: Subject: Re: Principled Handling of Breaking Changes To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Content-Type: multipart/alternative; boundary="0000000000007b54100613c4bd7f" Received-SPF: pass client-ip=2001:4860:4864:20::33; envelope-from=rudiwillalwaysloveyou@gmail.com; helo=mail-oa1-x33.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.58 X-Spam-Score: -9.58 X-Migadu-Queue-Id: 1D311631E5 X-TUID: +P8nsD5fJdeh --0000000000007b54100613c4bd7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > what other breaking changes caused problems for you? I remember these three: - `tab-width` - fontification in example blocks ( https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3D9daad41cc= ) - `org-fold-core-style` changing to `text-properties` (from `overlays`) broke custom code I had for coloring links. > Rather for Emacs in general. Would you be interested to post this > suggestion on emacs-devel list? That's also a good idea, but I don't remember being bitten by changes in emacs itself. It might help emacs adopt better defaults for new users though, as the backward compatibility of emacs makes its UX terrible for new users. > The very first section in https://orgmode.org/Changes.html lists > breaking and important changes. I don't care about "important changes" though, I just want the breaking changes ... I guess I should allocate the needed time for reading this anyway. Thanks. On Sat, Mar 16, 2024 at 1:48=E2=80=AFPM Ihor Radchenko wrote: > Rudi C writes: > > > The recent upgrades to Org mode have been a source of great frustration > for > > me. Many of the configurations I had previously set up stopped working = as > > intended, and it took me several days to properly identify the issues, > > debug them, and find suitable workarounds. > > Apart from the issue with tab-width you reported, what other breaking > changes caused problems for you? > > > To address this concern, I suggest that all breaking changes in Org mod= e > > follow a versioning scheme similar to Perl's `use v5.34.0;`. This could > be > > achieved by introducing an `org-defaults-use-version` variable, which > would > > be set to nil by default, allowing the package to adapt its behavior as > > necessary. However, when `org-defaults-use-version` is set to a specifi= c > > version, all configuration variables should adhere to the behavior > > associated with that particular version. Furthermore, I propose that al= l > > breaking changes be accompanied by a configuration flag, enabling users > to > > disable the change if they so desire. By implementing these suggestions= , > > users would be able to upgrade Org mode without the fear of spending > hours > > dealing with frustration and debugging. > > This might be a good idea, but not necessary for Org mode in particular. > Rather for Emacs in general. Would you be interested to post this > suggestion on emacs-devel list? > > > PS: Is there a changelog that ONLY lists breaking changes? There should > be > > one ... > > The very first section in https://orgmode.org/Changes.html lists > breaking and important changes. Users are free to limit reading the > changelog to this first section. It is not clear for me why we need a > separate page. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > --0000000000007b54100613c4bd7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> what other breaking changes caused problems for you?<= br>

I remember these three:

- `= tab-width`
- fontification in example blocks (https:= //git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3D9daad41cc)<= /div>
- `org-fold-core-style` changing to `text-properties` (from `over= lays`) broke custom code I had for coloring links.

> Rather for Emacs in general. Would you be interested to post this> suggestion on emacs-devel list?

That's also a= good idea, but I don't remember being bitten by changes in emacs itsel= f. It might help emacs adopt better defaults for new users though, as the b= ackward compatibility of emacs makes its UX terrible for new users.=C2=A0

> The very first section in=C2=A0https://= orgmode.org/Changes.html=C2=A0lists
> breaking and important ch= anges.

I don't care about "important changes&qu= ot; though, I just want the breaking changes ... I guess I should allocate = the needed time for reading this anyway.

Thanks.

On Sat, Mar 16, 2024 at 1:48=E2=80=AFPM Ihor Radchenko <yantar92@posteo.net> wrote:
Rudi C <rudiwillalwaysloveyou@gm= ail.com> writes:

> The recent upgrades to Org mode have been a source of great frustratio= n for
> me. Many of the configurations I had previously set up stopped working= as
> intended, and it took me several days to properly identify the issues,=
> debug them, and find suitable workarounds.

Apart from the issue with tab-width you reported, what other breaking
changes caused problems for you?

> To address this concern, I suggest that all breaking changes in Org mo= de
> follow a versioning scheme similar to Perl's `use v5.34.0;`. This = could be
> achieved by introducing an `org-defaults-use-version` variable, which = would
> be set to nil by default, allowing the package to adapt its behavior a= s
> necessary. However, when `org-defaults-use-version` is set to a specif= ic
> version, all configuration variables should adhere to the behavior
> associated with that particular version. Furthermore, I propose that a= ll
> breaking changes be accompanied by a configuration flag, enabling user= s to
> disable the change if they so desire. By implementing these suggestion= s,
> users would be able to upgrade Org mode without the fear of spending h= ours
> dealing with frustration and debugging.

This might be a good idea, but not necessary for Org mode in particular. Rather for Emacs in general. Would you be interested to post this
suggestion on emacs-devel list?

> PS: Is there a changelog that ONLY lists breaking changes? There shoul= d be
> one ...

The very first section in https://orgmode.org/Changes.html list= s
breaking and important changes. Users are free to limit reading the
changelog to this first section. It is not clear for me why we need a
separate page.

--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,=
or support my work at <https://liberapay.com/yantar92>
--0000000000007b54100613c4bd7f--