From: Tim Cross <theophilusx@gmail.com>
To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
Date: Thu, 09 Dec 2021 08:25:35 +1100 [thread overview]
Message-ID: <87pmq6u5sr.fsf@gmail.com> (raw)
In-Reply-To: <87lf0uvq9s.fsf@web.de>
"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.
next prev parent reply other threads:[~2021-12-08 21:49 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-05 7:35 Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal Ihor Radchenko
2021-12-05 9:16 ` Juan Manuel Macías
2021-12-05 10:24 ` Ihor Radchenko
2021-12-05 11:08 ` Juan Manuel Macías
2021-12-05 11:54 ` Heinz Tuechler
2021-12-05 12:08 ` Ihor Radchenko
2021-12-05 13:32 ` Tim Cross
2021-12-05 13:52 ` Bruce D'Arcus
2021-12-05 22:20 ` Tim Cross
2021-12-05 14:30 ` Ihor Radchenko
2021-12-05 22:39 ` Tim Cross
2021-12-08 13:47 ` Ihor Radchenko
2021-12-08 14:39 ` Tim Cross
2021-12-08 16:16 ` Dr. Arne Babenhauserheide
2021-12-08 17:07 ` Russell Adams
2021-12-08 19:22 ` Dr. Arne Babenhauserheide
2021-12-08 20:14 ` Russell Adams
2021-12-08 21:50 ` Tim Cross
2021-12-09 8:12 ` Dr. Arne Babenhauserheide
2021-12-08 21:25 ` Tim Cross [this message]
2021-12-09 8:07 ` Dr. Arne Babenhauserheide
2021-12-09 8:36 ` Timothy
2021-12-09 9:18 ` Ihor Radchenko
2021-12-09 10:46 ` Eric S Fraga
2021-12-09 15:21 ` Russell Adams
2021-12-09 16:25 ` Eric S Fraga
2021-12-09 21:15 ` Samuel Wales
2021-12-09 23:27 ` Dr. Arne Babenhauserheide
2021-12-10 2:42 ` Tim Cross
2021-12-10 6:08 ` Dr. Arne Babenhauserheide
2021-12-11 10:03 ` Ihor Radchenko
2021-12-11 21:19 ` Tim Cross
2021-12-06 19:41 ` Karl Voit
2021-12-05 18:59 ` Juan Manuel Macías
2021-12-05 23:24 ` Russell Adams
2021-12-06 5:57 ` Juan Manuel Macías
2021-12-06 6:02 ` Timothy
2021-12-06 7:24 ` Juan Manuel Macías
2021-12-06 10:04 ` Greg Minshall
2021-12-06 14:59 ` Juan Manuel Macías
2021-12-06 17:59 ` Tom Gillespie
2021-12-06 18:25 ` M. ‘quintus’ Gülker
2021-12-06 18:42 ` Russell Adams
2021-12-06 18:47 ` Timothy
2021-12-06 19:28 ` Russell Adams
2021-12-06 19:34 ` Timothy
2021-12-06 18:30 ` Russell Adams
2021-12-06 19:10 ` Gerry Agbobada
2021-12-08 12:56 ` Ihor Radchenko
2021-12-06 10:08 ` Greg Minshall
2021-12-06 19:45 ` Karl Voit
2021-12-07 11:08 ` Vincent Breton
2021-12-08 13:13 ` Ihor Radchenko
2021-12-08 13:30 ` Ihor Radchenko
2021-12-05 13:06 ` Tim Cross
2021-12-05 14:55 ` Ihor Radchenko
2021-12-05 18:54 ` Timothy
2021-12-06 11:08 ` Max Nikulin
2021-12-06 18:43 ` Russell Adams
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=87pmq6u5sr.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).