2018ko apirilak 29an, Tim Cross-ek idatzi zuen:

[...]

> I think org itself should provide a very stable core and avoid
> incorporating too many add on enhancements. It should be as stable as
> possible to encourage others to develop and maintain such enhancements
> and extensions. 

As someone who has worked (in a small way) on orgʼs development, I
certainly agree with the above sentiment.  Org is a many-headed
hydra, and decreasing its surface area makes for a better org (since
development efforts can be concentrated) as well as a better overall
user experience (because users can rely on packages, like in this
case yasnippet, that are better at doing something that Org tried to
do).

On the other hand, as an org user breaking changes are inconvenient.  I
have the impression that I can keep up with using org-mode only because
I follow the development list.  Whatʼs much worse, I feel like I should
not advocate the use of org-mode to my colleagues (who are often quite
computer-literate but value long-term stability of software they use),
basically because of the potential problems Bastien listed in his
message.

This situation is also inconvenient for developers...I have in mind a
change several years ago to the #+begin_src lines for shell code.  We
changed from #+begin_src shell to #+begin_src sh (or vice versa, I
canʼt remember precisely).  The result was that “bug” reports trickled
in for over a year, all of which had to be answered with the advice to
change to the new specification.  At the time I paid close attention to
babel-related bug reports because I was working on that code a lot.
Answering these reports (or even just reading them to see that they had
been answered by someone else) took away from my opportunity to do
(what I saw as) interesting things with orgʼs code.  I can only imagine
that for ML subscribers who were not as interested in babel bugs as I
was, the distraction could only have been worse.

As a general (idealized) principle, I think user-visible changes should
be phased in over at least one org major version.  I have no problem
with “intrusive” deprecation warnings, but abrupt changes in behavior
should be avoided.

Hereʼs what I imagine that could look like in the org-tempo case:

For org 9.X:
- Introduce the new functions and machinery for org-tempo as well as the
  new C-c C-, keybinding
- Enable org-tempo by default
- Show a user warning whenever a “<X” style template is being expanded,
  saying that this feature will go away in the next major version and to
  keep it, users should add “(require 'org-tempo)” to their .emacs
- Arrange matters so that users who take this step will not receive
  further warnings when expanding <X (this might require changing the
  activation trigger of org-tempo from a library to some other
  mechanism, see below)

For Org 10:
- No longer enable org-tempo by default
- Remove the logic for the deprecation warning

I would also question the decision to change the format of
org-structure-template-alist.  That has caused some errors (in the sense
of calls to the elisp ‘error’ function) for me because a third
party-library (ox-reveal) still uses the old format.  The change also
seems orthogonal to the switch from <X to C-c C-, expansion mechanism.
If itʼs really deemed to be important, I would suggest:

For org 9.X:
- Correctly handle alist keys in both new and old formats
- Show a deprecation warning if any old format keys are found in the
  alist

For Org 10:
- Remove the code to handle old-style keys and the deprecation warning.

Iʼm only too aware that this approach would increase the complexity
of developing new features, both in terms of code and needing to
coordinate addition/removal of bits of compatibility code across
multiple org versions.  It also requires some additional mental
effort since the deprecation path to follow is slightly different in
each case.  But I think this strikes a necessary balance between the
extremes of “UX must never change” and “UX can be revised at any
point”.

Finally, irrespective of which options are chosen, I think that org-tempo
would be better implemented in terms of a minor mode.  This would allow
it to be autoloaded, turned on/off for different buffer(s) in an emacs
session, and avoid duplicating the logic for activating global minor
modes.  Patch attached.

-- 
Aaron Ecay