Как я могу изящно отказаться от поддержки старых emacsen в моем пакете elisp?

Я поддерживаю довольно хорошо используемый пакет emacs (ido-vubiquitous), и в следующей версии я планирую отказаться от поддержки Emacs 23 и ниже. Люди, которые используют Emacs 23 и ниже, смогут продолжить использование текущей версии моего пакета.

Однако я не хочу, чтобы пользователи Emacs 23 обновлялись через ELPA или git или что-то еще и заканчивали новую версию, которая несовместима с их emacs. Есть ли общепринятый способ справиться с этим изящно? Есть ли у меня какой-либо выбор, не переименование новой версии на "ido-ubiquitous-ng" или что-то еще?

ОТВЕТЫ

Ответ 1

ЭЛПА /package.el

Чтобы предотвратить обновление через package.el, добавьте специальную зависимость (emacs "24.1") в список Package-Requires. См. Заголовки библиотек в руководстве Emacs Lisp в описании заголовка Package-Requires::

[...] Код пакета автоматически определяет пакет с именем 'emacs с номером версии текущего запуска Emacs. Это можно использовать для минимальной версии Emacs для пакета.

Пакет package, который распределяется независимо для Emacs 23 и ниже, предоставляет не этот специальный пакет. Таким образом, любая попытка установки вашего пакета на Emacs 23 завершится неудачей с сообщением о том, что "emacs" недоступен для установки, оставив старую совместимую версию на месте.

Однако при использовании этого будьте готовы обрабатывать жалобы от пользователей Emacs 24. Многие пользователи, по-видимому, не удаляют свои старые package.el при обновлении до Emacs 24. Таким образом, старый package.el переопределяет новый встроенный, приводящие к ложным ошибкам при установке.

ELGet

Я не знаю Эльгета. Вероятно, попросите своего автора помочь в этом вопросе.

Git подмодули, Tarballs и другие унаследованные методы

Я не думаю, что вы действительно можете предотвратить обновления, если пользователи установят ваш пакет устаревшим способом (например, Git подмодули, дистрибутивные пакеты и т.д.). Вы можете жаловаться только после обновления вашего пакета, что, возможно, слишком поздно, потому что теперь несовместимый код уже существует.

Вы можете добавить явную проверку версии с подробным error. Я считаю это лишним. Если вы действительно поедете на Emacs 24, вы будете использовать несовместимые функции, поэтому ваш пакет не будет загружаться успешно, независимо от того, явно ли вы его предотвращаете или нет. Поэтому сохраните лишний код:)

TL; DR (+ личный опыт)

Прежде всего, не переименуйте свой пакет. Немногие пользователи могут следить за новостями о каждом установленном пакете. Таким образом, многие пользователи не сразу осознают, что пакет был переименован и продолжают использовать устаревшую версию без предупреждения или предупреждения. Фактически, вы бы хотели наказать Emacs 24 пользователей вашего пакета.

Добавьте специальную зависимость для предотвращения случайных обновлений через package.el. Добавьте важную документацию, что ваш пакет требует Emacs 24, как в первом разделе вашего Github Readme. Тогда, давайте дело остальное. Что-нибудь еще, вероятно, больше хлопот, что это стоит.

В моем личном опыте пользователи Emacs не глупы (ну, по крайней мере, большинство нет). Они читают документацию. Они понимают документацию.

Пользователи Emacs 23 знают, что их Emacs устарел. Многие из них ожидают несовместимости и поломки. Если пакет внезапно сломается для них, они будут обращаться за советом к Github, понимают, что пакет больше недоступен для Emacs 23, и либо вернитесь к последнему рабочему выпуску, либо, надеюсь, обновите свои Emacs.