Re: Changed list indentation behavior: how to revert?

[Tim Cross <theophilusx@gmail.com>]

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