How to Downgrade/Rollback an Emacs Package

How to Downgrade/Rollback an Emacs Package

They don't exactly tell you in the tutorial, so a quick remedial course.

In our example today, let's say we want to downgrade org-node to 1.6.2.

With vc-use-package (built into Emacs from Emacs 30+): 

(use-package org-node
  :vc (:fetcher github :repo "meedstrom/org-node"
       :rev "6ed833d1025d5163137904f2a1f6d80d930610b4"))

With Quelpa: 

(use-package org-node
  :quelpa (org-node :fetcher github :repo "meedstrom/org-node"
                    :commit "6ed833d1025d5163137904f2a1f6d80d930610b4"))

With Elpaca as follows. Note that if you had already installed the package, modifying the recipe to include :tag will only take effect after you do M-x elpaca-delete RET org-node RET and have it re-install. The idea is that Elpaca users will prefer to do this kind of thing manually inside the cloned repo. 

(use-package org-node
  :ensure (:fetcher github :repo "meedstrom/org-node"
           :tag "1.6.2"))

With Straight, it's a bit different, since it cannot pin a commit nor a tag directly. Three methods:

  1. Create a Straight lockfile.
  2. If you know about Git, enter the cloned repo (M-x find-library RET org-node RET) and check out an old commit yourself. Tip: if you cannot see many old commits in the Git log, first run the command git fetch --unshallow.
  3. Easiest: Hope that the author made a branch for an old version.

It turns out we can use method #3 this time because org-node does have a branch for the 1.6.x series: 

(use-package org-node
  :straight (org-node :type git :host github :repo "meedstrom/org-node"
                      :branch "v1.6"))

Bonus: Find out the installed version of a package🔗

You've probably seen a line like this near the top of an Emacs Lisp source file: 

;; Version: 2.2.2

or 

;; Package-Version: 2.2.2

Unfortunately, this number is not always present, nor is it always to be believed. It depends on the author's development style.

So unless you only install from GNU/NonGNU ELPA, which mandate the above line, it's worth knowing a reliable method specific to your package-manager:

  • Elpaca
    • type M-x elpaca-info RET org-node RET
  • Straight, Borg and anything that uses Git clones
    • go to M-x find-library RET org-node RET
    • then run the Git command git log --tags --pretty="%ci %d"
      • if that yields no answers, run git fetch --unshallow and try again
        • if still no answers, the ;; Version: line is right
  • The built-in package.el
    • If it came from MELPA Stable, look inside the autogenerated file org-node-pkg.el, because they'll put the tag there. Primary MELPA still needs to revamp their version naming scheme before they can do the same – correlate with the date.

Bonus: Explore past versions to find the correct commit🔗

The examples on this page were easy because org-node is a package that uses Git tags: we can see on the tags page that tag 1.6.2 corresponds to commit 6ed833d1025d5163137904f2a1f6d80d930610b4.

Alternatively, Straight users can check the branches page and hope that the author has seen fit to spin off branches for some old versions.

But what to do if there are no tags or branches? That occurs in two cases:

  1. The author doesn't version at all
  2. The author only updates the ;; Package-Version: header inside the source file. Typical on the GNU ELPA.

As far as I can tell, GNU and NonGNU ELPA use some specialized tool to crawl the commit history to look for the version header. I don't know what that tool is. So as an user, for now I'd just visit the commits page and pick any random old commit to try.

Created (5 weeks ago)