10

I maintain a fairly well-used emacs package (ido-ubiquitous), and in the next version I plan to drop support for Emacs 23 and below. People who use Emacs 23 and below will be able to continue using the current version of my package.

However, I don't want to have Emacs 23 users upgrading via ELPA or git or something else and ending up with the new version that isn't compatible with their emacs. Is there a generally accepted way of handling this gracefully? Do I have any choice short of renaming the new version to "ido-ubiquitous-ng" or something?

Ryan C. Thompson
  • 40,856
  • 28
  • 97
  • 159
  • For ELPA, you could make your package depend on `emacs-24`, though I'm not sure if that would give the desired user experience. – legoscia May 29 '13 at 08:06

1 Answers1

7

ELPA/package.el

To prevent updates via package.el, add the special dependency (emacs "24.1") to the Package-Requires list. See Library Headers in the Emacs Lisp Manual, in the description of the Package-Requires: header:

[…] The package code automatically defines a package named ‘emacs’ with the version number of the currently running Emacs. This can be used to require a minimal version of Emacs for a package.

The package.el which is distributed independently for Emacs 23 and below does not provide this special package. Thus, any attempt to install your package on Emacs 23 will fail with a message complaining about “emacs” being unavailable for installation, leaving the old, compatible version in place.

However, when using this, be prepared to handle complaints from users of Emacs 24. Many users apparently do not delete their old package.el when upgrading to Emacs 24. Thus the old package.el overrides the new built-in one, leading to spurious errors on installation.

ELGet

I do not know Elget. Probably ask its author for help in this matter.

Git submodules, Tarballs and other legacy methods

I do not think, that you can really prevent updates, if users install your package in a legacy way (e.g. Git submodules, distribution packages, etc.). You can only complain after your package was updated, which is arguably too late, because the incompatible code is now already there.

You may choose to add an explicit version check, with a detailed error. I consider this superfluous, though. If you really go for Emacs 24, you will be using incompatible functions, so your package won't load successfully, whether you explicitly prevent it or not. So save yourself of superfluous code :)

TL;DR (+ personal experience)

First of all, please do not rename your package. Few users can follow the news on each and every installed package. Thus many users will not immediately realize that the package was renamed, and continue to use an outdated version without notice or warning. Effectively, you would sort of punish Emacs 24 users of your package.

Add the special dependency to prevent accidental updates via package.el. Add prominent documentation, that your package requires Emacs 24, like in the first section of your Github Readme. Then, let the matter rest. Anything else is likely more hassle that it is worth.

In my personal experience, Emacs users are not stupid (well, at least the majority isn't). They read documentation. They understand documentation.

Users of Emacs 23 know that their Emacs is outdated. Many of them expect incompatibilities and breakage. If the package suddenly breaks for them, they will seek advice on Github, realize that the package is not available for Emacs 23 anymore, and either go back to the last working release, or (hopefully) upgrade their Emacs.

Community
  • 1
  • 1
  • 2
    Regardless of package manager dependencies, make sure that (assuming your library is in version control!) you create a branch for the Emacs 23 version of the library before you start hacking on the trunk. That way users at least retain the ability to grab a compatible version from the repository (and with an appropriate el-get source/recipe, could trivially install and update from the Emacs 23 branch specifically). – phils May 29 '13 at 09:10
  • @phils Wouldn't a tag on the last compatible version be sufficient, if he does not intend to support Emacs 23 any more? –  May 29 '13 at 09:19
  • To my mind this is definitely a case for a branch. Tags would be used for specific releases within a branch. Even if you don't plan to support it, not branching discounts the possibility of accepting patches from other people (but I'd still call it a branch regardless of that). With a VCS like git, tags and branches are conveniently very nearly the same thing. With the likes of Subversion branching *is* more heavyweight, however it would be a rare Emacs library which had a repository so large as to make that a concern. – phils May 29 '13 at 09:26
  • @phils Well, obviously a tag would mark the last compatible release. In my opinion a branch would suggest that Emacs 23 is still actively supported, which does not seem to be the OP's intention. He wants to drop support, and a tag conveys this message more than a branch, imho. Should there be need, a branch can still be created later on, based on this tag. –  May 29 '13 at 09:43
  • Thanks for the answer. I'll be taking all this into account. I've already crested a separate branch in git, and I'll add the emacs 24 dependency for ELPA. And I'm one of the el-get authors, so I'll figure that out myself :). – Ryan C. Thompson May 29 '13 at 22:08