10

我维护了一个相当常用的 emacs 包（ido-ubiquitous），并且在下一个版本中我计划放弃对 Emacs 23 及更低版本的支持。使用 Emacs 23 及以下版本的人将能够继续使用我的包的当前版本。

但是，我不想让 Emacs 23 用户通过 ELPA 或 git 或其他方式进行升级，最终得到与他们的 emacs 不兼容的新版本。是否有一种普遍接受的方式来优雅地处理这个问题？除了将新版本重命名为“ido-ubiquitous-ng”之类的东西之外，我还有什么选择吗？

4

1 回答 1

7

ELPA/package.el

要防止通过 package.el 进行更新，请将特殊依赖项添加(emacs "24.1")到Package-Requires列表中。请参阅Emacs Lisp 手册中的Library Headers，在Package-Requires:标题的描述中：

[…] 包代码自动定义了一个名为“emacs”的包，其中包含当前运行的 Emacs 的版本号。这可用于要求包的 Emacs 最低版本。

为 Emacs 23 及以下版本独立分发的 package.el不提供此特殊包。因此，任何在 Emacs 23 上安装软件包的尝试都将失败，并显示一条消息，抱怨“emacs”无法安装，而保留旧的兼容版本。

package.el但是，在使用它时，请准备好处理 Emacs 24 用户的投诉。许多用户在升级到 Emacs 24 时显然不会删除他们的旧版本。因此旧版本package.el会覆盖新的内置版本，从而导致安装时出现虚假错误。

ELGet

我不知道埃尔盖特。可能在这件事上向其作者寻求帮助。

Git 子模块、Tarballs 和其他遗留方法

我不认为，如果用户以传统方式（例如 Git 子模块、分发包等）安装您的包，您真的可以阻止更新。你只能在你的包更新后抱怨，这可以说为时已晚，因为不兼容的代码现在已经存在了。

您可以选择添加显式版本检查，并带有详细的error. 不过，我认为这是多余的。如果您真的选择 Emacs 24，那么您将使用不兼容的功能，因此无论您是否明确阻止它，您的包都不会成功加载。所以省去多余的代码:)

TL;DR（+个人经验）

首先，请不要重命名您的包。很少有用户可以关注每个已安装软件包的新闻。因此，许多用户不会立即意识到软件包已重命名，而是继续使用过时的版本，而不会发出通知或警告。实际上，你会惩罚你的包的 Emacs 24 用户。

添加特殊依赖项以防止通过 package.el 意外更新。添加重要的文档，说明您的包需要 Emacs 24，就像在 Github 自述文件的第一部分中一样。然后，让事情过去吧。其他任何事情都可能比它更有价值。

以我个人的经验，Emacs 用户并不愚蠢（嗯，至少大多数不是）。他们阅读文档。他们了解文档。

Emacs 23 的用户知道他们的 Emacs 已经过时了。他们中的许多人预计不兼容和破损。如果软件包突然损坏，他们会在 Github 上寻求建议，意识到该软件包不再适用于 Emacs 23，然后返回上一个工作版本，或者（希望）升级他们的 Emacs。

于 2013-05-29T08:11:09.460 回答