emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Adam Porter <adam@alphapapa.net>
Cc: emacs-orgmode@gnu.org
Subject: Re: Policy proposal: Do not move existing functions/macros except in major version increments
Date: Thu, 23 Apr 2020 13:26:17 +0200	[thread overview]
Message-ID: <87eesejvdy.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87a732hpiu.fsf@alphapapa.net> (Adam Porter's message of "Wed, 22 Apr 2020 22:03:37 -0500")

Hello,

Adam Porter <adam@alphapapa.net> writes:

> Of course, I am biased here, but I feel like it's not quite as
> exceptional as it ought to be.  The more Org-related packages I make and
> maintain, the more version-specific workarounds I have to add due to
> changed function names, signatures, etc.  These are sometimes necessary,
> of course, but I think they should be made more carefully and
> deliberately.
>
> Of course, Org doesn't make any promises to third-party packages.  But
> that is the issue, isn't it?  I'm saying that I think it should start
> taking this issue a little more seriously.  :)

[...]

> That is a matter of policy, which is what I'm proposing.  When such a
> change is desired (symbol name, function signature, etc), it should be
> targeted at the next major version increment.  If the project as a whole
> is not ready to make that increment, that change should be delayed until
> then--it can be developed in a branch and merged when preparing the
> major release.  These kinds of changes could even be documented in
> advance, e.g. in a ROADMAP or PLANS file, or whatever you want to call
> it, which would be more explicit and referenceable than merely a mailing
> list post.

I think it isn't a realistic policy, because it is not even close to how
Org development happens.

Unlike what you write, even with a smiley, I am taking compatibility
issues and breakages as seriously as I can. I do my best to not
introduce them in the first place, and, if I do, because I think that's
for the better, I do my best to make the transition easier. Yet,
breakage happens, and I am sincerely sorry about that. Now, fire me if
you want.

However, please remember that Org development happens in a best effort,
and in a somewhat opportunistic, fashion. Most internal changes, and
therefore breakages, stem off a bug report or an enhancement request,
not from a big ROADMAP file in the sky. Call it amateurism, but I think
it is in its most noble meaning.

Maybe in the not-so-distant future, professional-minded folks will lead
the project, defining road maps, strict rules for features integration,
proper issue tracking, and whatnot. And maybe that will be a good thing.
Any help is welcome. Until then, we have two branches:

1. master, where breakage can happen, which implies at least minor
   version numbers bumps.

2. maint, where breakage is to be avoided at all cost, which implies
   only bugfix version number bumps.

Close to a release, we also happen to have "feature-freeze" periods. In
that situation, development happens in a temporary third branch: next.

You may consider it to be an insufficient policy, but AFAICT, this is
all we have at the moment, and, possibly, all we can afford, too.

Of course, this is only my opinion. I wouldn't dare talking for other
developers. AFAIC, I already do all I can, with the time I have;
I cannot follow your policy.

> That is a good idea, and one that needs addressing.  I'd be glad to give
> some feedback on it, but in a separate thread, please, because it seems
> like a different matter from the issue I'm raising and the proposal I'm
> making.

I thought most third-party breakages came from misuse of internal
functions in Org. But if you say it is orthogonal, and that I am
off-topic, so be it.

Regards,

-- 
Nicolas Goaziou


  reply	other threads:[~2020-04-23 11:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17  2:16 Policy proposal: Do not move existing functions/macros except in major version increments Adam Porter
2020-04-17  9:03 ` Nicolas Goaziou
2020-04-23  3:03   ` Adam Porter
2020-04-23 11:26     ` Nicolas Goaziou [this message]
2020-06-01 15:11 ` Bastien
2020-06-01 18:07   ` Adam Porter
2020-06-01 22:59     ` Bastien

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=87eesejvdy.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=adam@alphapapa.net \
    --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).