New from Emacs 31.1 - Upgrade packages without breaking other Emacsen

(Date: 14 September 2026)

Summary

From Emacs 31.1, there is a user option to keep previous versions of packages when upgrading packages; in order not to break separate instances of Emacs which may be still running and using the previous package versions. This allows you to continue to use several concurrent versions that you may be using. This is easy to use with with (setopt package-retention-policy t).

Introduction

In February 2026, I introduced the idea of introducing an option when upgrading packages, to keep previous versions of packages, with an initial patch that was merged to master as Commit 0ca70400965. (th initial name of the option was package-upgrade-keep-previous)

See bug (Bug#79957) and See part of the initial bug discussion

This was subsequently improved and generalised by Philip Kaludercic (pkal) with more fine-grained control, so you can for example apply it on a package basis, amongst other things. This useful generalisation is described in the variable further down.

As Philip says, “the generalization is supposed to make the user option more similar to ‘package-review-policy’; … preserving old installations makes it easier to revert an upgrade (though that is not always possible, if the package makes some non-backwards compatible changes to the system).”

For background, see e.g. here and here

In Emacs 31.1, you can read up about the changes in Emacs in NEWS, accessible with C-h n:

*** New user option ’package-retention-policy’. This user option controls what previous packages versions to keep on upgrade. By default, this is set to nil, to keep the previous behavior.

The details of how to use the new variable that allows keeping old package versions as well as generalisations is here you can see with C-h v described as:

package-retention-policy is a variable defined in ‘package.el’.

Its value is t Original value was nil

Policy for retaining old package installations after upgrades. By default Emacs will activate the newest package, unless otherwise specified using ‘package-load-list’. If this user option is set to t, then no old packages are deleted. This might be useful if you wish to revert an upgrade. By setting this user option to a list you can also selectively list what packages and archives to retain. For the former, an entry of the form (archive STRING) will retain all packages from the archive STRING (see ‘package-archives’), and an entry of the form (package SYMBOL) will retain packages whose names match SYMBOL. If you prefix the list with a symbol ‘not’, the rules are inverted.

This variable was introduced, or its default value was changed, in version 31.1 of Emacs. You can customize this variable.

See also the Emacs Info manual (emacs) Package Installation

Packages are most conveniently installed using the package menu (*note Package Menu::), but you can also use the command ‘M-x package-install’. This prompts for the name of a package with the ‘available’ status, then downloads and installs it. Similarly, if you want to upgrade a package, you can use the ‘M-x package-upgrade’ command, and if you want to upgrade all the packages, you can use the ‘M-x package-upgrade-all’ command. By default, these commands will delete old installations, but you can adjust that behavior by customizing the variable ‘package-retention-policy’.

So, to use this feature, simply include this code in your init file:

(setopt package-retention-policy t)

Motivation to resolve the initial problem

It is useful to run multiple Emacsen concurrently, for several reasons, some of which include the following.

Running multiple Emacs is an easy and powerful way to make use of multi-core processors. Emacs has a single-threaded Lisp. Although there are ways to run multiple threads within in Emacs, it is not used everywhere is complicated, and from the point view of the Emacs Lisp interpreter, appears impractical. Therefore running different Emacs processes is a simple and effective way to leverage parallelism.

There are other reasons, such as simplificity of isolation. For Emacs developers, the ability to write and run new Lisp code in a separate Emacs is also useful to avoid breaking others.

Since the introduction of packages in Emacs, using and upgrade packages is a frequent part of using Emacs. Some Emacs sessions may require updates of packages, some instances may be working fine without upgrades, but do require their own packages not to be deleted. A example is if you are using Emacs A for one purpose, and Emacs B for LaTeX editing, using the AUCTeX package for example, using a dedicated Emacs session. This Emacs B can be a longer-running session.

The problem is that if you upgrade Emacs A, by default it replaces packages and deletes previous versions. If you have another Emacs running and upgrade packages there, it can break the second Emacs.

So preserving the previous package versions makes it practical to upgrade one Emacs instance separate from others.

Further work.

There is further work in this area, to use the packages upgraded elsewhere. In the terminology above. I have been working on a prototype to load up packages upgraded from Emacs A but unknown to Emacs B. The function allows Emacs B to ‘catch-up’. It should work in many circumstances without requiring a restart.

See (Bug#79957) for ideas of design.

Conclusion

You can use this new option from Emacs 31.1