Re: Policy proposal: Do not move existing functions/macros except in major version increments

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

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