[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Policy proposal: Do not move existing functions/macros except in maj
From: |
Bastien |
Subject: |
Re: Policy proposal: Do not move existing functions/macros except in major version increments |
Date: |
Tue, 02 Jun 2020 00:59:10 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) |
Hi Adam,
Adam Porter <adam@alphapapa.net> writes:
> I mostly agree with you. My request is simply that, when a change
> has the potential to break third-party packages, and it's a change,
> such as this one, that mostly moves code around for organizational
> purposes, that it be delayed until the next major version.
IIRC this was the case for the change that triggered your first email,
it was in master, no?
> My goal for such a policy would be to reduce the frequency of such
> changes that third-party package authors have to write compatibility
> code for. The (if (version< org-version ...)) workarounds become
> confusing for authors and users, and somewhat of a maintenance
> burden.
I understand the burden. We don't really follow the conventions of
semantic versioning. We use "x.y.z" versions with z being for bugfix
releases and both y and x for... the rest.
Because we are slow at releasing so-called minor releases, they end up
containing some changes that users and developers should be aware of.
Hence the need to let them know about such changes. I don't think
using a policy will help here, because definitions of "breaking" may
vary: is a change in a function's signature always a breaking change?
For every function? Or just for core functions? If so, which ones?
(See the many discussions in the npm universe about what to consider
a breaking change and worth a major release.)
In a word: even though stricter rules could somehow help, I do think
the main issue is about *communication*, not conventions.
> That's a very clever way to do it! Thanks for your work on this.
Thanks, I hope it will be useful.
> If
> it's feasible, you might also consider allowing committers to put such
> a header in the git commit log and parsing it out of that, which could
> make it even easier.
The idea is that updates that are important enough to be listed on
updates.orgmode.org are the ones that *should* be somehow announced on
the mailing list. If we let updates.orgmode.org monitor commits, then
people who are only reading the list will miss updates (which we
don't want, I think.)
That said, it would be nice to have a function that checks the data
from https://updates.orgmode.org/data/updates and warn the user when
there is a new upcoming change.
--
Bastien