emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Tom Gillespie <tgbugs@gmail.com>
Cc: "Dr. Arne Babenhauserheide" <arne_bab@web.de>,
	emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Changed list indentation behavior: how to revert?
Date: Tue, 17 Nov 2020 07:56:56 +1100	[thread overview]
Message-ID: <87sg999g13.fsf@gmail.com> (raw)
In-Reply-To: <CA+G3_PN3Vc9dR_pQcO7gbwy_Peo1MZ4d3rkkWcbQ+-ZWEVDvvA@mail.gmail.com>


Tom Gillespie <tgbugs@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 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


  parent reply	other threads:[~2020-11-16 20:58 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13 17:30 Changed list indentation behavior: how to revert? Karl Voit
2020-11-13 21:10 ` Gustavo Barros
2020-11-13 21:38   ` Jean Louis
2020-11-14  3:02     ` Greg Minshall
2020-11-13 21:47   ` Jean Louis
2020-11-13 22:13     ` Gustavo Barros
2020-11-13 22:21       ` Jean Louis
2020-11-14 17:28         ` Diego Zamboni
2020-11-14 19:10           ` Jean Louis
2020-11-15 12:44             ` Kévin Le Gouguec
2020-11-15 13:26               ` Jean Louis
2020-11-15 21:59                 ` Kévin Le Gouguec
2020-11-15 22:15                   ` Jean Louis
2020-11-16  7:15                   ` Dr. Arne Babenhauserheide
2020-11-16  6:26               ` Greg Minshall
2020-11-14 10:45   ` Diego Zamboni
2020-11-13 21:31 ` Jean Louis
2020-11-14 22:43 ` David Rogers
2020-11-15  5:38   ` Jean Louis
2020-11-15  7:47     ` David Rogers
2020-11-15  8:54       ` Jean Louis
2020-11-15 10:37       ` Greg Minshall
2020-11-15 11:42         ` Tim Cross
2020-11-15 11:48         ` Gustavo Barros
2020-11-15 11:58           ` Detlef Steuer
2020-11-15 12:09           ` Jean Louis
2020-11-15 14:50             ` Gustavo Barros
2020-11-15 15:11               ` Jean Louis
2020-11-15 10:44       ` Dr. Arne Babenhauserheide
2020-11-15 11:22         ` Detlef Steuer
2020-11-15 14:03           ` Kévin Le Gouguec
2020-11-16  5:24             ` Kyle Meyer
2020-11-16  6:41               ` Tim Cross
2020-11-16  7:15                 ` Tim Cross
2020-11-16 11:21                   ` Gustavo Barros
2020-11-16 23:24                     ` T.F. Torrey
2020-11-17  1:21                       ` Tom Gillespie
2020-11-17  7:01                         ` Dr. Arne Babenhauserheide
2020-11-17  7:48                       ` Michal Politowski
2020-11-19  4:17                     ` Marcel Ventosa
2020-11-16  8:06                 ` Kévin Le Gouguec
2020-11-16 12:10                 ` Bill Burdick
2020-11-16  6:54               ` Greg Minshall
2020-11-16  7:12                 ` Tim Cross
2020-11-17  4:03                   ` Greg Minshall
2020-11-17  5:25                     ` Tim Cross
2020-11-17 13:15                       ` Greg Minshall
2020-11-16  7:01               ` Dr. Arne Babenhauserheide
2020-11-16  7:22                 ` Tim Cross
2020-11-16 16:04                   ` Dr. Arne Babenhauserheide
2020-11-16 16:26                     ` Tom Gillespie
2020-11-16 18:12                       ` gyro funch
2020-11-16 18:48                         ` Tom Gillespie
2020-11-16 19:41                           ` Bill Burdick
2020-11-16 19:56                             ` Tom Gillespie
2020-11-16 21:50                             ` Tim Cross
2020-11-16 23:01                               ` Tom Gillespie
2020-11-16 21:44                           ` Tim Cross
2020-11-16 18:20                       ` gyro funch
2020-11-16 20:56                       ` Tim Cross [this message]
2020-11-16 21:35                         ` Bill Burdick
2020-11-16 22:44                         ` Tom Gillespie
2020-11-16 23:55                         ` Dr. Arne Babenhauserheide
2020-11-17  9:05                           ` Stefan Nobis
2020-11-17  9:15                             ` Loris Bennett
2020-11-17  9:32                             ` Diego Zamboni
2020-11-17 14:29                             ` Dr. Arne Babenhauserheide
2020-11-17 16:25                               ` Robert Pluim
2020-11-16 23:39                       ` Dr. Arne Babenhauserheide
2020-11-16 21:35                     ` Tim Cross
2020-11-17  0:11                       ` Dr. Arne Babenhauserheide
2020-11-17  8:45                         ` Detlef Steuer
2020-11-17  9:41                           ` Jean Louis
2020-11-17 15:33                     ` Maxim Nikulin
2020-11-16 13:00                 ` Uwe Brauer
2020-11-16 16:10                   ` Dr. Arne Babenhauserheide

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sg999g13.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=arne_bab@web.de \
    --cc=emacs-orgmode@gnu.org \
    --cc=tgbugs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).