From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id qjDUAd/nsl/RGAAA0tVLHw (envelope-from ) for ; Mon, 16 Nov 2020 20:58:07 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id +zPSON7nsl8QbQAAB5/wlQ (envelope-from ) for ; Mon, 16 Nov 2020 20:58:06 +0000 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 8A46B94021E for ; Mon, 16 Nov 2020 20:58:06 +0000 (UTC) Received: from localhost ([::1]:60728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kelZd-0002SE-Ci for larch@yhetil.org; Mon, 16 Nov 2020 15:58:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48218) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kelYe-0002NC-Vh for emacs-orgmode@gnu.org; Mon, 16 Nov 2020 15:57:05 -0500 Received: from mail-pg1-x530.google.com ([2607:f8b0:4864:20::530]:39709) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kelYc-0007rG-Vt for emacs-orgmode@gnu.org; Mon, 16 Nov 2020 15:57:04 -0500 Received: by mail-pg1-x530.google.com with SMTP id p68so3839492pga.6 for ; Mon, 16 Nov 2020 12:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:message-id :date:mime-version; bh=uaor6zqqWNDX3jjhJoY64ziLTXEJSkaLR6OUdPVMrH8=; b=TBu+C9yKOVnibZbH1FpQHeEi4tshwHHiJMeCP4+nMIrdVvV466RFP2DsUz2iDBM5BX C1nHjkdjRJO96hMxqZx2G75tSIJqqUyvP3i1BQDYiOhlF/noykaJjbRTBYe1pqYFq7i0 QzEyzpptOWJS+0dgRHGxojiKeFFGuHDLM6ClnICMROMvaPvDujr4aREGwsaFp3C/nud/ m9WYNwWpvH9NeNSMZboeTNnnT1cl2w+3irHu6kSDhYSHqkF+8RRu1O8aODqSwCPB0zrh CMT7oNDwrnbm2QCYVBYAbVN+9IFSM7griKd9iY/eW9TGOlHAv7bRYEbCeoVjZqrB6dqJ KBZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:message-id:date:mime-version; bh=uaor6zqqWNDX3jjhJoY64ziLTXEJSkaLR6OUdPVMrH8=; b=ugXRYay+hfcEFH4OItBTvYZ6FhOv/4WG8y/5dAT3VYkEXEOoPr9Y2vZUWBjkQyEcVE l5Vec9EZGaDx74eOkvixJ27dqpTO+5YEWUntevaEPR0cAKteLKyGbGgN2ZFeJQTDBvBk AYefHQJOr0p4siq6pl7Yib9HxZE6q71Io/Z2nOWu63ZDzFPGHEWEEaAxbB1sQaLBQeAo ZC2Dqt8vC/cCP1PZluunBR0krz6JpTnlc4aACxyqRGPgQ2oErbKSe6CS2XMg0kumACcG ZUSlx2LtnvS8Qbr8GtxqsZfPuCAebH7U0YzGe3jQ7eSIFTxCPmp7UOpGeXCfiN32aGtv jReQ== X-Gm-Message-State: AOAM531lAavW0oL3KSgDdPWv+TDTVC/ji1MYTyFHWf8VPONk6BPNUjM8 AvrvAABgvrSmoEZqXJy9a324jxD19fyF/w== X-Google-Smtp-Source: ABdhPJyrENR41fHLunq1DZIGR/u/dU+gAeMyiNw4lalVcmhVfB1Js8GmUFmv3nvJYCUFMjVjqyT00A== X-Received: by 2002:a17:90a:b118:: with SMTP id z24mr819742pjq.108.1605560220975; Mon, 16 Nov 2020 12:57:00 -0800 (PST) Received: from tim-desktop (106-69-116-104.dyn.iinet.net.au. [106.69.116.104]) by smtp.gmail.com with ESMTPSA id k8sm18896318pfh.6.2020.11.16.12.56.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Nov 2020 12:57:00 -0800 (PST) References: <2020-11-13T18-23-43@devnull.Karl-Voit.at> <874klqew77.fsf@web.de> <20201115122154.50ad1503@linux-h0yu.fritz.box> <87tutq67ka.fsf@gmail.com> <87tutpvppm.fsf@kyleam.com> <871rgtwzrs.fsf@web.de> <87y2j1ahqf.fsf@gmail.com> <87v9e5uw2u.fsf@web.de> User-agent: mu4e 1.5.7; emacs 27.1.50 From: Tim Cross To: Tom Gillespie Subject: Re: Changed list indentation behavior: how to revert? In-reply-to: Message-ID: <87sg999g13.fsf@gmail.com> Date: Tue, 17 Nov 2020 07:56:56 +1100 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::530; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x530.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Dr. Arne Babenhauserheide" , emacs-orgmode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=TBu+C9yK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.71 X-TUID: l2GqQ6/Fumwl Tom Gillespie writes: > Would it help if major releases maintained a mini-config that if added > to init.el would allow users to retain old behavior? That way they > wouldn't have to read the NEWS but could just add the relevant lines, > or maybe even just call the org-old-default-behavior-9.1 or > org-old-default-behavior-9.4. The workflow during development would be > to account for any change to defaults in those functions. Thoughts? > Tom If people don't have time to read the NEWS file, I also doubt they would be aware of the mini config file or have the time to add it to their setup. There would be an additional burden on developers to maintain the mini-config which might not actually result in any real benefit. I would also be concerned this might setup an expectation which is difficult to meet. It may not always be straight-forward to provide such a mini-config and sometimes, it may actually be in the best interests of the user to force a change on them because it brings other benefits that outweigh the initial 'change pain'. I do wonder if Org would benefit from adopting semantic versioning? This could provide a way to convey more information to the user in the version number e.g x.y.z => MAJOR.MINOR.PATCH where - PATCH = bug fix only. No changes to API or interface - MINOR = extensions (additions) to API or interface, but no change to existing API and interface - MAJOR = breaking change - either API or interface has changed In general, my experience has been that the org developers have worked hard to keep things stable in a very complex environment. The challenge is when there is a breaking change, how to effectively communicate this and minimise surprises for the user and how to accurately gauge the impact from a change. At the same time, us users also need to take on some of the responsibility and recognise that major version upgrades may break or change their workflow. If you have a situation where stability of your environment is critical to your work and your strapped for time so that any change will be unacceptably disruptive, you need to adopt an upgrade workflow which mitigates that risk. For example, my workflow allows me to roll back any package which I upgrade. If I upgrade a package and it breaks things and I don't have time to troubleshoot, I can roll it back. Some distributions also include this feature. This is one area where I feel the ELPA system could be improved. Right now, if you use the org-plus-contrib package (or the org package) from either the org or melpa package, it reports as something like org-plus-contrib-20201118, which tells me very little apart from there is an update. I cannot tell from this name if it is a major, minor or bug fix update. Not a big deal for me as I can always roll back, but not everyone has that ability. Change is inevitable and if we focus too much on not changing existing behaviour or API, we run the risk of overly constraining development. Communication of change is a challenge, but critically important. I feel we would get the most benefit by focusing on how to communicate breaking changes effectively and ensure when such change is introduced, as far as possible, details on how to restore the previous behaviour are provided. -- Tim Cross