Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Tim Cross <theophilusx@gmail.com>]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> [[PGP Signed Part:Undecided]]
>
> Russell Adams <RLAdams@AdamsInfoServ.Com> writes:
>
>> On Wed, Dec 08, 2021 at 05:16:20PM +0100, Dr. Arne Babenhauserheide wrote:
>>>
>>> Tim Cross <theophilusx@gmail.com> writes:
>>>
> To date, I only had a bigger problem once (and that hurt a lot, because
> it was just before giving a lecture, so I had to ditch most of the
> improvements I wanted to do and instead spend all the time fixing the
> document), but the talk here about “sometimes you have to break
> compatibility” goes into a direction I consider as very dangerous.
>
> Please do not make org-mode volatile.¹
>
> Org-Mode and Emacs have mostly been stable the past 15 years. And it is
> good to be stable; a strength that is highlighted much too seldomly.
>

Nobody is suggesting we make org-mode volatile. However, it expect that
there will never be breaking change is idealistic. I cannot think of a
single piece of software which hasn't at some point had some level of
breaking change. 

As I stated in my post, backwards compatibility is important and no
breaking change should be taken lightly. However, at times, it is
necessary and cannot be avoided. It might even be outside org-mode's
control - for example, a breaking change in Emacs might result in the
need for a change in org-mode or a security vulnerability might be
discovered which cannot be fixed without a breaking change.

Change is inevitable. It cannot be prevented. All we can do is try to
mitigate the impact of that change as best we can. Of course you also
have the choice to avoid such changes simply by not upgrading. While
this will mean you don't get bug fixes or enhancements, it is really the
only way to guarantee your documents are not impacted.

I think org-mode has a pretty good track record. There have been
breaking changes, but those changes have been in the main, justified and
never done lightly. They have bene documented and included in the NEWS
file and org has provided tools like rog-lint and conversion functions
to help with the transition required for such change.

Change is inevitable and sometimes, breaking change cannot be avoided.
It is a fact of life we have to deal with. As developers, we need to try
and ensure the impact from change is as minimal as possible and when it
is inevitable, we implement the change in a planned manner which tries
to reduce that impact (communication, conversion facilities and
conversion functions, stage implementation, deprecation periods etc).

What really doesn't help is to immediately jump to extremes and start
talking about making something volatile just because change is
mentioned.