emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Bill Burdick <bill.burdick@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: Tom Gillespie <tgbugs@gmail.com>,
	"Dr. Arne Babenhauserheide" <arne_bab@web.de>,
	emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Changed list indentation behavior: how to revert?
Date: Mon, 16 Nov 2020 23:35:36 +0200	[thread overview]
Message-ID: <CAP6X8DjjZefePbJCr8sdtfNJEWHC4HJeQZdYecHKp9jcA34Quw@mail.gmail.com> (raw)
In-Reply-To: <87sg999g13.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3665 bytes --]

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 <theophilusx@gmail.com> wrote:

>
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 4405 bytes --]

  reply	other threads:[~2020-11-16 21:36 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
2020-11-16 21:35                         ` Bill Burdick [this message]
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=CAP6X8DjjZefePbJCr8sdtfNJEWHC4HJeQZdYecHKp9jcA34Quw@mail.gmail.com \
    --to=bill.burdick@gmail.com \
    --cc=arne_bab@web.de \
    --cc=emacs-orgmode@gnu.org \
    --cc=tgbugs@gmail.com \
    --cc=theophilusx@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).