我维护了一个相当常用的 emacs 包(ido-ubiquitous),并且在下一个版本中我计划放弃对 Emacs 23 及更低版本的支持。使用 Emacs 23 及以下版本的人将能够继续使用我的包的当前版本。
但是,我不想让 Emacs 23 用户通过 ELPA 或 git 或其他方式进行升级,最终得到与他们的 emacs 不兼容的新版本。是否有一种普遍接受的方式来优雅地处理这个问题?除了将新版本重命名为“ido-ubiquitous-ng”之类的东西之外,我还有什么选择吗?
我维护了一个相当常用的 emacs 包(ido-ubiquitous),并且在下一个版本中我计划放弃对 Emacs 23 及更低版本的支持。使用 Emacs 23 及以下版本的人将能够继续使用我的包的当前版本。
但是,我不想让 Emacs 23 用户通过 ELPA 或 git 或其他方式进行升级,最终得到与他们的 emacs 不兼容的新版本。是否有一种普遍接受的方式来优雅地处理这个问题?除了将新版本重命名为“ido-ubiquitous-ng”之类的东西之外,我还有什么选择吗?
要防止通过 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
会覆盖新的内置版本,从而导致安装时出现虚假错误。
我不知道埃尔盖特。可能在这件事上向其作者寻求帮助。
我不认为,如果用户以传统方式(例如 Git 子模块、分发包等)安装您的包,您真的可以阻止更新。你只能在你的包更新后抱怨,这可以说为时已晚,因为不兼容的代码现在已经存在了。
您可以选择添加显式版本检查,并带有详细的error
. 不过,我认为这是多余的。如果您真的选择 Emacs 24,那么您将使用不兼容的功能,因此无论您是否明确阻止它,您的包都不会成功加载。所以省去多余的代码:)
首先,请不要重命名您的包。很少有用户可以关注每个已安装软件包的新闻。因此,许多用户不会立即意识到软件包已重命名,而是继续使用过时的版本,而不会发出通知或警告。实际上,你会惩罚你的包的 Emacs 24 用户。
添加特殊依赖项以防止通过 package.el 意外更新。添加重要的文档,说明您的包需要 Emacs 24,就像在 Github 自述文件的第一部分中一样。然后,让事情过去吧。其他任何事情都可能比它更有价值。
以我个人的经验,Emacs 用户并不愚蠢(嗯,至少大多数不是)。他们阅读文档。他们了解文档。
Emacs 23 的用户知道他们的 Emacs 已经过时了。他们中的许多人预计不兼容和破损。如果软件包突然损坏,他们会在 Github 上寻求建议,意识到该软件包不再适用于 Emacs 23,然后返回上一个工作版本,或者(希望)升级他们的 Emacs。