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 cKXgMeTwsl8TYAAA0tVLHw (envelope-from ) for ; Mon, 16 Nov 2020 21:36:36 +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 sM24LeTwsl/BHQAA1q6Kng (envelope-from ) for ; Mon, 16 Nov 2020 21:36:36 +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 3A4CF940538 for ; Mon, 16 Nov 2020 21:36:36 +0000 (UTC) Received: from localhost ([::1]:57136 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kemAs-0000lp-Jx for larch@yhetil.org; Mon, 16 Nov 2020 16:36:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58776) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kemAC-0000j5-HP for emacs-orgmode@gnu.org; Mon, 16 Nov 2020 16:35:53 -0500 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:39728) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kemAA-0000a1-2S for emacs-orgmode@gnu.org; Mon, 16 Nov 2020 16:35:52 -0500 Received: by mail-lj1-x233.google.com with SMTP id o24so21811735ljj.6 for ; Mon, 16 Nov 2020 13:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IpG2XIM0gxw7TBztK0yhflL94jCB9nLGS+9g/sXIFCA=; b=Cp0LALCVwpHty1+kCdSC8Z70N4Up85+kbxNSxB6M7elg48kk6UlkZpARAY0KBSIgSb /kuDWj2oyOW2vL62gju0iv7haJA102au8i0fwP47QMfu6/LLGZPmtbNbuh1lw5WR50Ly AMD38Rwcg47gnoI90+BqvmJCtvgYZY1B9knUR+6hN8pfv/9t7JsKifp5e5ayXZ54znf4 Q/yqJR4B8RepKnlzj32Oua/FT5UHSsf+LmXf+SZDni8+SOjXy+19YmDdGX31ut/HyUxg oPkJrvarP1fGyefC/FLS/9DdIeuN6kdYmQTLRA64daxcflArAfMOHzpmnLosx94jAJsJ Fvqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IpG2XIM0gxw7TBztK0yhflL94jCB9nLGS+9g/sXIFCA=; b=fRUznne3TSTIAh2owv8Rl7uRYrZqyXFGg5srs+cygW/jC51gNFan+a6g+HzPueTueN 9+SA8j+ERas3MePHqq8ON4XZOCZTUv0xNkKF9KqIuMFv1yG3LGph4Kr7Pru9OEFQimy+ Jqh2O8VBm9XWtIcdWgniO8vKN+3rxCWQ+T4Ea5c8FbkoKGrLgMCvl9kNywwjxo0xu+io DUyw1+Zg6Zzil4sG0zNMxd1HCW9N1wlXmXLV74IkWMusGTBAfuKs6aMYA+QlsH56ejmh TwboeNZTkTXXDaeB/hU3mH4D3dgfBG61HOyCz9yKZs7SDXH7AFODSFE6e+HrHRJTPIxt U6mQ== X-Gm-Message-State: AOAM533UJYK/gXtRrzEM9R01GSnkJfOvhjdReFSsh76Q+gROzTJcgtzB dB4qXfEODN4A4hQ8HrvQ1hJOpfNS07VQSF/OUFM= X-Google-Smtp-Source: ABdhPJzKG2rGkY3ZXT2YzhSwXpeFGTKwthIVDwY2OlunwrY86D1W+8VScq5EeR4jLOnMIhBQnr7BKnQ3QAOi4EByAMw= X-Received: by 2002:a2e:96c6:: with SMTP id d6mr560212ljj.48.1605562547073; Mon, 16 Nov 2020 13:35:47 -0800 (PST) MIME-Version: 1.0 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> <87sg999g13.fsf@gmail.com> In-Reply-To: <87sg999g13.fsf@gmail.com> From: Bill Burdick Date: Mon, 16 Nov 2020 23:35:36 +0200 Message-ID: Subject: Re: Changed list indentation behavior: how to revert? To: Tim Cross Content-Type: multipart/alternative; boundary="00000000000048763205b440299c" Received-SPF: pass client-ip=2a00:1450:4864:20::233; envelope-from=bill.burdick@gmail.com; helo=mail-lj1-x233.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, HTML_MESSAGE=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: Tom Gillespie , "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=Cp0LALCV; 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: c/u+u8lW3Y8v --00000000000048763205b440299c Content-Type: text/plain; charset="UTF-8" Heh, I had time to read EMACS NEWS when I used it in 1985 (and still do for new EMACS versions). Now there are soooo many packages, each with their own news... -- Bill On Mon, Nov 16, 2020 at 10:59 PM Tim Cross wrote: > > 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 > > --00000000000048763205b440299c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Heh, I had time to read EMACS NEWS when I used it in 1985 = (and still do for new EMACS versions). Now there are soooo many packages, e= ach with their own news...


-- Bill


On Mon, Nov 16, 2020 at 10= :59 PM Tim Cross <theophilusx@g= mail.com> wrote:

Tom Gillespie <tgb= ugs@gmail.com> 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 lin= es,
> 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 woul= d
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 =3D> MAJOR.MINOR.PATCH where

- PATCH =3D bug fix only. No changes to API or interface
- MINOR =3D extensions (additions) to API or interface, but no change to =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 existing API and interface
- MAJOR =3D 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

--00000000000048763205b440299c--