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 回答