Charles Choi has a very informative post on the Emacs upgrading policy a very informative post on the Emacs upgrading policy. The TL;DR is that by default Emacs’ package.el will not upgrade packages that are builtin. Org is an example of this. The package is builtin but the Org team issues updates much more frequently than Emacs itself is upgraded. There’s a variable, package-install-upgrade-built-in, that can override this behavior and force package.el to upgrade packages whether or not they’re builtin.
When I read his post, I thought, “This is great. It’s the answer to why Org sometimes doesn’t upgrade correctly.” But then I realized that Org is upgraded by package.el even though package-install-upgrade-built-in is set to nil on my system.
So now I don’t know what’s going on. Org is certainly a builtin package but it doesn’t seem to be behaving in the manner described by Choi and the documentation. Choi’s use case involves transient, which he depends on for his Casual suite. He needed a later version but it was not upgraded for at least one of his users.
Perhaps the policy is restricted to the update of dependencies although the documentation does not reflect that. Fortunately, this is Emacs and all the source is available and hackable so it’s just a matter of digging into the code to see what’s going on. Perhaps I’ll do that in the near future but for now it’s enough to know that someone has thought about the issue and attempted a solution.
Updates
:
Philip Kaludercic explains what’s going on in this comment. What package-install-upgrade-built-in really does is interpret built-in as installed. Take a look at the comment for the full explanation.
:
Added link to Choi’s post.