all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@posteo.net>
To: Tim Cross <theophilusx@gmail.com>
Cc: Bastien <bzg@gnu.org>,  emacs-orgmode@gnu.org
Subject: Re: [MAINTENANCE] Do we have any backwards-compatibility policy for third-party packages?
Date: Thu, 17 Nov 2022 12:04:30 +0000	[thread overview]
Message-ID: <87cz9lbxdd.fsf@localhost> (raw)
In-Reply-To: <86wn7ubflw.fsf@gmail.com>


> It might be worthwhile defining what is meant by 3rd party packages.
>
> For example, ob-scheme relying on geiser as a 3rd party package is one
> thing. Org roam is another type of 3rd party package. I think they need
> different approaches. The first is about our (org) interface to them and
> the latter is about their (org roam) interface with org.

Sorry for not being clear.
I was referring to third-party packages Org optionally depends on.
Like geiser or citeproc or engrave-faces.

> For the former (e.g. geiser type), I don't think backwards compatibility
> is as important. Thanks to package.el and GNU ELPA/NONGNU ELPA, it is
> fairly trivial to update to the current version. We just need to support
> the current version.

Yes, but what if, say, the newest geiser version no longer supports the
Emacs version Org still supports?

> For the latter (e.g. org-roam), backwards compatibility is much more
> important. Org needs to provide as stable a public API for such packages
> as possible. It may even be worthwhile separating the API into a
> public/external API and an internal/private API. The former would be as
> stable as possible and when changes are made, all efforts to provide
> backwards compatibility are made. The latter is also stable, but more
> subject to change. It is the API intended for internal org use. If
> external packages use it, it is at their own risk. We would still try to
> keep it stable, but with less of a guarantee and we may not provide
> backwards compatibility if doing so was going to cause too much
> complexity or maintenance burden etc.

That's what we already do.
I mean, https://bzg.fr/en/the-software-maintainers-pledge/ :)

Public/private is the usual org-* vs. org--*.
We never break org-*. Even if we do, we first deprecate things.

> The big thing here is IMO avoiding surprise. We probably should add a
> section to the 'Hacking' section of the manual which outlines our
> position wrt backwards compatibility and API (public/private) and change
> etc. I think most people expect change (even if they might not like
> it). What they don't like is unexpected change. As long as we are
> conservative and communicate change when necessary, we will likely be
> OK.

I hope that we never had unexpected changes. Isn't it for granted? I
felt like it was always the case in Org and Emacs forever.

It feels so obvious that I cannot even figure out how we could clarify
it in the manual.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


  reply	other threads:[~2022-11-17 12:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11  3:41 [MAINTENANCE] Do we have any backwards-compatibility policy for third-party packages? Ihor Radchenko
2022-11-16 22:33 ` Tim Cross
2022-11-17 12:04   ` Ihor Radchenko [this message]
2022-11-17 23:38     ` Tim Cross
2022-12-10 13:48       ` Ihor Radchenko
2022-12-11  3:24         ` Tim Cross
2022-12-18 12:45         ` Ihor Radchenko
2022-12-11 10:20       ` Ihor Radchenko

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cz9lbxdd.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=bzg@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@gmail.com \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.