From: Tim Cross <theophilusx@gmail.com>
To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: Changed list indentation behavior: how to revert?
Date: Tue, 17 Nov 2020 08:35:18 +1100 [thread overview]
Message-ID: <87pn4d9e95.fsf@gmail.com> (raw)
In-Reply-To: <87v9e5uw2u.fsf@web.de>
Dr. Arne Babenhauserheide <arne_bab@web.de> writes:
> Tim Cross <theophilusx@gmail.com> 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’s
> 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’ve been more liberal on that point before I saw the problems that
> 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
next prev parent 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
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 [this message]
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=87pn4d9e95.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=arne_bab@web.de \
--cc=emacs-orgmode@gnu.org \
/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).