"Dr. Arne Babenhauserheide" <arne_...@web.de> writes:
> [[PGP Signed Part:Undecided]] > > Russell Adams <rlad...@adamsinfoserv.com> writes: > >> On Wed, Dec 08, 2021 at 05:16:20PM +0100, Dr. Arne Babenhauserheide wrote: >>> >>> Tim Cross <theophil...@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.
