From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id eI4+Bs/wsl8TYAAA0tVLHw (envelope-from ) for ; Mon, 16 Nov 2020 21:36:15 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id yE4ZAs/wsl+xHQAA1q6Kng (envelope-from ) for ; Mon, 16 Nov 2020 21:36:15 +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 9C51B9403AA for ; Mon, 16 Nov 2020 21:36:14 +0000 (UTC) Received: from localhost ([::1]:56538 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kemAX-0000U0-9K for larch@yhetil.org; Mon, 16 Nov 2020 16:36:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58674) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kem9o-0000To-BW for emacs-orgmode@gnu.org; Mon, 16 Nov 2020 16:35:28 -0500 Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]:43895) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kem9k-0000W8-LJ for emacs-orgmode@gnu.org; Mon, 16 Nov 2020 16:35:28 -0500 Received: by mail-pf1-x42a.google.com with SMTP id i8so1681974pfk.10 for ; Mon, 16 Nov 2020 13:35:24 -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:content-transfer-encoding; bh=LgMos3vqiPnbEKYwv/fhMAmfBIh30Da7D4o1jvr+kbc=; b=qo1W2t5KL9shZru+0xx6WEYuqzQf3f3NOBtVSKmY24vq6HIoqvNzU1Kn9W5LvlHLXZ RE2OoO0LKC4FiIIamGKOSyhJ+ysU/rAl0hpO3t2SNae6QmrXJbkmWcrRuTap68qNCJHM mPf/PhRrzMsejCtqjINUoiGkQ1PkWpx0ef9Af/3BO5oDUUhlukH043E7ECdv2IX2B+Y6 kDOedRSg48hgSKrekkEyngpb9rrE25P927qw7pXfTLts7c8iIM+YHZReTypmrp8SC/k8 dDO/DnXdrziwBbI3AlZWhGYVJ92IE4YLuzUqF9P3vvS1n+QLHY0jXI3YO7OcP2wprbfq z+LQ== 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:content-transfer-encoding; bh=LgMos3vqiPnbEKYwv/fhMAmfBIh30Da7D4o1jvr+kbc=; b=ubhZGOC4cv676rJKRicHMXzMWyGXi2imOJhAgBQ1Nr1+SvgSGyi1lcY1yxu/nLm6Zh Gmu+mgRc9MJHsUfGUx997g2YtT3wBFLgHA3L7ZK1iCaNmjM3vcA092d1iO8LlVHPMzIT DJ7NzeaJL0z/Sd9Hj49x57UYNZmB4JYjW2G1L5Mvwxj4hys4OmgrFIndufhS6KkMgwak P3RynfJ5v9ZVrwCeLoowvl36lwFQWecwsQqcdgufnJdsOuzHnqgIxM179NNRojkVWozU xUymg2OJ2idEeZZpjAq7/NGFpTdJu6+SOBux1+k3UhNdrBhl0FPb+XWomiFv8YGbxLjf 2ctQ== X-Gm-Message-State: AOAM532obAwFH513JpaeXR0L9th+FLqxnh95XnCYI4vro/2E9UH2Rraz CLPhEIi30sexjpjAgxvGVRGmAx9L6A1HrA== X-Google-Smtp-Source: ABdhPJx983txNwKxNpGIZa+tYOIAMKRoisEl/c1CPDfjs/hvN7RuhY4udmyjtOuwjP8WHq2Eo2pdqw== X-Received: by 2002:a17:90a:3d0b:: with SMTP id h11mr959452pjc.108.1605562522598; Mon, 16 Nov 2020 13:35:22 -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 t74sm18825962pfc.47.2020.11.16.13.35.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Nov 2020 13:35:21 -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: "Dr. Arne Babenhauserheide" Subject: Re: Changed list indentation behavior: how to revert? In-reply-to: <87v9e5uw2u.fsf@web.de> Message-ID: <87pn4d9e95.fsf@gmail.com> Date: Tue, 17 Nov 2020 08:35:18 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::42a; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x42a.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: emacs-orgmode@gnu.org 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=qo1W2t5K; 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: hrzfn9CMhati Dr. Arne Babenhauserheide writes: > Tim Cross writes: >> I can completely understand your position. However, I wanted to point >> out that this change was documented in the org NEWS file, where all >> version changes are documented. When upgrading to a new version of org, >> everyone should look there, ideally before the upgrade or soon >> afterwards and definitely when you notice some changed behaviour. It >> will save hours of trouble shooting and often tells you how to restore >> previous behaviour. A very under appreciated piece of valuable >> documentation. > > I would like to agree, because I wish people would also read NEWS for my > projects, but since I use at least 10-20 programs daily which depend on > hundreds of libraries that might change their behavior, that=E2=80=99s > unrealistic. > > I cannot read NEWS entries whenever my distro updates org-mode, > therefore I depend on org-mode not breaking during updates. > > If an update changes behavior in a way that requires people to read up > on stuff to find out how to continue working, that means that the > program breaks with that update. > > I=E2=80=99ve been more liberal on that point before I saw the problems th= at > arose from the Python2->Python3 transition. Many changes that each seem > small on their own can cause significant damage, because there will > always be some people that get hit by them during a period in their life > when they cannot follow them, because they are fully occupied by work > (mentally or because of little time) so the tools they trained with must > just keep working. > I understand where your coming from, but feel you are over stating the problem. The Python version change is an extreme example. The maintainers of Python made the decision that such a fundamental change was critically important for the long-term viability of the language and there was no way to implement that change which was not going to be extremely disruptive. I don't know enough about the internals of Python to have an opinion on whether it was a good or bad decision. There are only two mechanisms by which org-mode is upgraded and as far as I know, both require that the user either initiates the update or turns on automatic updates. Your argument would be more compelling for me if we were talking about updates which occur without user intervention or control. Org is only updated if you update your OS distribution to a new major version and the version of Emacs is updated (or you manually update Emacs) or you use the MELPA or org repositories and request an upgrade. The ELPA system also includes the ability to 'pin' a package to a specific version to prevent upgrades. Change is inevitable and such changes will from time to time, break things. If stability in an environment is the priority, then it is up to the user who maintains that environment to manage things in such a way as to preserve that stability. Developers of tools and libraries cannot bare that responsibility because they cannot accurately assess how change will impact all users in all environments. Their responsibility is to effectively communicate what has changed to enable the user/maintainer to make the appropriate decisions regarding what to upgrade and when and to not introduce arbitrary changes that are not justified. To expect things to never change is unrealistic. With respect to the current issue about line indentation. I think the key question here is was communication of this change sufficient and if not, what can be done to make such communication more effective. It would seem, for whatever reason, few people read the NEWS file, so perhaps other mechanisms need to be introduced. I have mentioned in another message that semantic versioning might be one way to help users manage updates, but I'm sure there are other and likely more effective ideas out there that could help. Perhaps some documentation on what people can do to improve stability in their environments e.g. pinning ELPA packages to specific versions, implementing package rollback functionality, etc. Tim -- Tim Cross