我維護一個相當常用的emacs包（ido-ubiquitous），在下一個版本中，我打算放棄對Emacs 23和更低版本的支持。使用Emacs 23及以下版本的用戶可以繼續使用我的軟件包的當前版本。如何在我的elisp軟件包中優雅地放棄對舊emacsen的支持？
但是，我不希望Emacs 23用戶通過ELPA或git或其他方式進行升級，並且以與emacs不兼容的新版本結束。有一種普遍接受的方式來優雅地處理這個問題嗎？我有什麼選擇可以將新版本重命名爲「ido-ubiquitous-ng」或其他？
爲了防止更新通過package.el，添加特殊依存(emacs "24.1")到Package-Requires列表。見Library Headers所述的Emacs Lisp手冊中，在Package-Requires:頭的描述：
[...]包代碼自動定義了一個名爲「emacs的與所述當前正在運行的Emacs的版本號包。這可以用來爲包提供一個最小版本的Emacs。
其爲Emacs 23獨立分佈和下面不不提供這個特殊的包中的package.el。因此，任何試圖在Emacs 23上安裝軟件包的嘗試都會失敗，並顯示一條消息，抱怨「emacs」無法安裝，只保留舊的兼容版本。
然而，使用這種時候，準備處理從Emacs的24的用戶抱怨很多用戶顯然不刪除舊package.el升級到Emacs的24時，因此老package.el覆蓋新的內置於一體，leading to spurious errors on installation。
我不知道Elget。大概問問作者在這件事情上的幫助。
我不認爲，你可以真正防止更新，如果用戶在傳統的方式安裝的軟件包（如Git的子模塊，分發包，等等。）。您只能在之後投訴，因爲您的軟件包已更新，這可能太晚了，因爲不兼容的代碼現在已經存在。
您可以選擇添加一個明確的版本檢查，其中包含詳細的error。不過，我認爲這是多餘的。如果你真的使用Emacs 24，你將使用不兼容的函數，所以你的包不會成功加載，無論你是否明確地阻止它。所以，拯救自己的多餘代碼:)
首先，請不要重命名你的包。幾乎沒有用戶可以關注每個安裝的軟件包的消息。因此，許多用戶不會立即意識到該軟件包已重新命名，並且繼續使用過時的版本，恕不另行通知或警告。實際上，你會懲罰你的軟件包的Emacs 24用戶。
添加特殊依賴關係以防止通過package.el意外更新。添加顯着的文檔，您的軟件包需要Emacs 24，就像在Github自述文件的第一部分中一樣。然後，讓事情休息。其他任何可能更麻煩，這是值得的。
在我的個人的經驗，Emacs的用戶並不愚蠢（好吧，至少大多數不是）。他們閱讀文件。他們理解文檔。
Emacs 23的用戶知道他們的Emacs已經過時。他們中的許多人認爲不兼容和破損。如果軟件包突然中斷，他們會在Github上尋求建議，意識到該軟件包不再適用於Emacs 23，並且可以返回上一個工作版本，或者（希望）升級它們的Emacs。
無論包管理器依賴關係如何，確保（假定您的庫在版本控制中！）在您開始對主幹進行黑客入侵之前，您爲庫的Emacs 23版本創建了一個分支。這樣，用戶至少可以保留從存儲庫獲取兼容版本的能力（並且具有適當的el-get源代碼/配方，可以特別安裝並從Emacs 23分支進行更新）。 – phils
@phils如果他不打算再支持Emacs 23，那麼最後一個兼容版本上的標籤是不是足夠了？ – lunaryorn
在我看來，這絕對是一個分支的情況。標籤將用於分支中的特定版本。即使你不打算支持它，也不會分支折扣接受來自其他人的補丁的可能性（但我仍然稱它爲一個分支，無論如何）。對於像git這樣的VCS，標籤和分支都是非常方便的東西。隨着Subversion等分支*更重量級，但它會是一個罕見的Emacs庫，其中有一個存儲庫如此龐大，以至於擔心。 – phils
對於ELPA，您可以使您的軟件包依賴於'emacs-24'，但我不確定這是否會提供所需的用戶體驗。 – legoscia