bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Adam Porter]

Hi,

Browsing the NEWS file for the first Emacs 29 pretest, I was glad to see
the following new commands:

     +++
     *** New command 'package-update'.
     This command allows you to upgrade packages without using 'M-x
     list-packages'.

     +++
     *** New command 'package-update-all'.
     This command allows updating all packages without any queries.

But, IMHO, these commands should be named 'package-upgrade' and
'package-upgrade-all'.

In my experience in GNU/Linux systems and other software, the verb
"update" is commonly used to refer to updating the list of available
packages and their versions without changing the installed versions of
packages (e.g. in Debian, "apt update"), while the verb "upgrade" is
used to refer to actually installing newer versions of packages
(e.g. "apt upgrade", or GNU Guix's "guix upgrade").  This terminology 
mirrors the inverse, i.e. "downgrading"; it's not said that packages are 
"downdated" or "backdated."

Even the first NEWS entry seems to suggest this conflation, as it says,
"This command allows you to upgrade packages...".

If it's not too late to make this change, I think it would be
worthwhile, as I think it would help prevent confusion for many users.
OTOH, if Emacs 29 is released with "update packages" meaning "to upgrade
packages to newer versions", we may be stuck with this confusing
language for a long time.

Thanks for your consideration, and for your work on Emacs.

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Eli Zaretskii]

> Date: Mon, 10 Apr 2023 07:53:52 -0500
> From: Adam Porter <adam@alphapapa.net>
> 
>      +++
>      *** New command 'package-update'.
>      This command allows you to upgrade packages without using 'M-x
>      list-packages'.
> 
>      +++
>      *** New command 'package-update-all'.
>      This command allows updating all packages without any queries.
> 
> But, IMHO, these commands should be named 'package-upgrade' and
> 'package-upgrade-all'.

These commands exist for the last year.  I'm not sure how reasonable
it is to rename them now, they are probably used in umpteen places
outside Emacs already.  Maybe if we leave behind an alias.

And what if someone teaches these commands to downgrade as well, at
some future time?

Does anyone else have an opinion?  Lars, Stefan, Philip?

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 10 Apr 2023 07:53:52 -0500
>> From: Adam Porter <adam@alphapapa.net>
>> 
>>      +++
>>      *** New command 'package-update'.
>>      This command allows you to upgrade packages without using 'M-x
>>      list-packages'.
>> 
>>      +++
>>      *** New command 'package-update-all'.
>>      This command allows updating all packages without any queries.
>> 
>> But, IMHO, these commands should be named 'package-upgrade' and
>> 'package-upgrade-all'.
>
> These commands exist for the last year.  I'm not sure how reasonable
> it is to rename them now, they are probably used in umpteen places
> outside Emacs already.  Maybe if we leave behind an alias.
>
> And what if someone teaches these commands to downgrade as well, at
> some future time?
>
> Does anyone else have an opinion?  Lars, Stefan, Philip?

I don't think that "update" and "upgrade" have that clear of a semantic
difference in practice to necessitate a renaming.  E.g. Debian's "apt"
distinguishes between updating (ie. synchronising the local repository
state) and upgrading (fetching and installing newer versions of a
package), while Fedora's dnf bundles both into one step and refers to it
as updating.

The term "update" probably has a minor edge over "upgrade" since it is a
more popular term, that users are more likely to search for.

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> I don't think that "update" and "upgrade" have that clear of a semantic
> difference in practice to necessitate a renaming.

I'd tend to agree.


        Stefan

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Dmitry Gutov]

On 10/04/2023 17:31, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
>> I don't think that "update" and "upgrade" have that clear of a semantic
>> difference in practice to necessitate a renaming.
> I'd tend to agree.

Here's an argument in favor of renaming:

These commands use the term 'update'. But package-menu-mark-upgrades, 
which has been in package.el for years, uses the term 'upgrade' in its 
name and its docstring ("all upgradable packages", etc). There are a few 
auxiliary functions which also use that term, but this is the 
public-facing one.

So now we have divergent terminology. Which implies that there is some 
difference between "upgrading" and "updating" in package.el, while there 
is none.

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>>> I don't think that "update" and "upgrade" have that clear of a semantic
>>> difference in practice to necessitate a renaming.
>> I'd tend to agree.
>
> Here's an argument in favor of renaming:
>
> These commands use the term 'update'. But package-menu-mark-upgrades, which
> has been in package.el for years, uses the term 'upgrade' in its name and
> its docstring ("all upgradable packages", etc). There are a few auxiliary
> functions which also use that term, but this is the public-facing one.
>
> So now we have divergent terminology. Which implies that there is some
> difference between "upgrading" and "updating" in package.el, while there
> is none.

Good point.

It's annoyingly late to rename, but if we rename without compatibility
aliases (which seems to be an option since these are new in Emacs-29),
then I'd be in favor.
     

        Stefan

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> I don't think that "update" and "upgrade" have that clear of a semantic
>>>> difference in practice to necessitate a renaming.
>>> I'd tend to agree.
>>
>> Here's an argument in favor of renaming:
>>
>> These commands use the term 'update'. But package-menu-mark-upgrades, which
>> has been in package.el for years, uses the term 'upgrade' in its name and
>> its docstring ("all upgradable packages", etc). There are a few auxiliary
>> functions which also use that term, but this is the public-facing one.

I have to admit that I didn't even notice that the command used the word
upgrade... Probably because I only invoked it using the binding, though
I do get the point with it being inconsistent.

>> So now we have divergent terminology. Which implies that there is some
>> difference between "upgrading" and "updating" in package.el, while there
>> is none.
>
> Good point.
>
> It's annoyingly late to rename, but if we rename without compatibility
> aliases (which seems to be an option since these are new in Emacs-29),
> then I'd be in favor.

What are compatibility aliases?  I must have missed something?

>         Stefan

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> It's annoyingly late to rename, but if we rename without compatibility
>> aliases (which seems to be an option since these are new in Emacs-29),
>> then I'd be in favor.
>
> What are compatibility aliases?  I must have missed something?

I thought we'd rename `package-update` to `package-upgrade` by adding
the new name and marking the old name as an obsolete alias (a
"compatibility alias").

I hadn't realized that `package-update` hasn't been in a release yet, so
we don't need such a compatibility alias.


        Stefan

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dmitry Gutov <dmitry@gutov.dev>,  Adam Porter <adam@alphapapa.net>,  Eli
>  Zaretskii <eliz@gnu.org>,  Lars Ingebrigtsen <larsi@gnus.org>,
>   62750@debbugs.gnu.org
> Date: Wed, 12 Apr 2023 09:22:03 -0400
> 
> >> It's annoyingly late to rename, but if we rename without compatibility
> >> aliases (which seems to be an option since these are new in Emacs-29),
> >> then I'd be in favor.
> >
> > What are compatibility aliases?  I must have missed something?
> 
> I thought we'd rename `package-update` to `package-upgrade` by adding
> the new name and marking the old name as an obsolete alias (a
> "compatibility alias").
> 
> I hadn't realized that `package-update` hasn't been in a release yet, so
> we don't need such a compatibility alias.

Even though these commands were available under those names for the
last year or so?

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> I hadn't realized that `package-update` hasn't been in a release yet, so
>> we don't need such a compatibility alias.
> Even though these commands were available under those names for the
> last year or so?

Well, that's for you to judge :-)


        Stefan

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> It's annoyingly late to rename, but if we rename without compatibility
>>> aliases (which seems to be an option since these are new in Emacs-29),
>>> then I'd be in favor.
>>
>> What are compatibility aliases?  I must have missed something?
>
> I thought we'd rename `package-update` to `package-upgrade` by adding
> the new name and marking the old name as an obsolete alias (a
> "compatibility alias").
>
> I hadn't realized that `package-update` hasn't been in a release yet, so
> we don't need such a compatibility alias.

If this were to happen, I'd like to also be able to rename the analogous
package-vc commands to upgrade as well.

(On a related topic I have been wondering if package-update should
handle package-vc packages at all, or if that was a mistake?)

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[João Távora]

On Wed, Apr 12, 2023 at 2:45 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> >>> It's annoyingly late to rename, but if we rename without compatibility
> >>> aliases (which seems to be an option since these are new in Emacs-29),
> >>> then I'd be in favor.
> >>
> >> What are compatibility aliases?  I must have missed something?
> >
> > I thought we'd rename `package-update` to `package-upgrade` by adding
> > the new name and marking the old name as an obsolete alias (a
> > "compatibility alias").
> >
> > I hadn't realized that `package-update` hasn't been in a release yet, so
> > we don't need such a compatibility alias.
>
> If this were to happen, I'd like to also be able to rename the analogous
> package-vc commands to upgrade as well.
>
> (On a related topic I have been wondering if package-update should
> handle package-vc packages at all, or if that was a mistake?)

Also, in the off-chance that no-one has noticed yet the new
package-update-*commands and the older package-menu*upgrade
commands use entirely different logic to discover what _can_
be updated.  Only by sheer skill or luck will this logic match exactly.

João

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Dmitry Gutov]

On 12/04/2023 16:34, Stefan Monnier wrote:
>>> I hadn't realized that `package-update` hasn't been in a release yet, so
>>> we don't need such a compatibility alias.
>> Even though these commands were available under those names for the
>> last year or so?
> Well, that's for you to judge 😄

Since they're not very likely to be used in Lisp code, I'd say it's 
unlikely to be a problem.

Alternatively, we'll probably get around to fixing this inconsistency 
sometime after this release, and then carry the compatibility aliases 
for a number of years.

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Jim Porter]

On 4/11/2023 2:28 PM, Dmitry Gutov wrote:
> These commands use the term 'update'. But package-menu-mark-upgrades, 
> which has been in package.el for years, uses the term 'upgrade' in its 
> name and its docstring ("all upgradable packages", etc). There are a few 
> auxiliary functions which also use that term, but this is the 
> public-facing one.

Given this, I think we should rename the functions. If that means adding 
obsolete aliases to be polite, that's ok too. (Personally, I don't think 
it's necessary, since users tracking the development builds should 
expect some minor breakage, but it doesn't hurt to have aliases.)

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Dmitry Gutov]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

On 15/04/2023 04:34, Dmitry Gutov wrote:
> On 12/04/2023 16:34, Stefan Monnier wrote:
>>>> I hadn't realized that `package-update` hasn't been in a release 
>>>> yet, so
>>>> we don't need such a compatibility alias.
>>> Even though these commands were available under those names for the
>>> last year or so?
>> Well, that's for you to judge 😄
> 
> Since they're not very likely to be used in Lisp code, I'd say it's 
> unlikely to be a problem.
> 
> Alternatively, we'll probably get around to fixing this inconsistency 
> sometime after this release, and then carry the compatibility aliases 
> for a number of years.

Here's a couple of other existing functions:

   package--update-selected-packages
   package--update-downloads-in-progress

Neither of these relate to upgrading packages. Although the former could 
be easy to mistake for that now.

In all older functions, the term "update" (in comments and variable 
names) refers to updating the value of some variable, not packages.

By analogy, 'M-x package-update-all' might be easy enough to mistake for 
updating the list of packages available for installation, for example.

Here's a patch that does the rename. Also including package-vc-update* 
that Philip mentioned.

[-- Attachment #2: 0001-Rename-all-functions-called-package-update-to-packag.patch --]
[-- Type: text/x-patch, Size: 8537 bytes --]

From 13ff1f26da07f7302e898638ef4a5341c2913948 Mon Sep 17 00:00:00 2001
From: Dmitry Gutov <dmitry@gutov.dev>
Date: Mon, 24 Apr 2023 02:00:54 +0300
Subject: [PATCH] Rename all functions called package-*-update-* to
 package-*-upgrade-*

* lisp/emacs-lisp/package-vc.el (package-vc-upgrade-all):
Rename from 'package-vc-update-all'.
(package-vc-upgrade): Rename from 'package-vc-update'.

* lisp/emacs-lisp/package.el (package-upgrade):
Rename from 'package-update' (bug#62750).
(package--upgradeable-packages):
Rename from 'package--updateable-packages'.
(package-upgrade-all): Rename from 'package-update-all'.
---
 doc/emacs/package.texi        | 14 +++++++-------
 etc/NEWS                      |  6 +++---
 lisp/emacs-lisp/package-vc.el | 18 +++++++++---------
 lisp/emacs-lisp/package.el    | 34 +++++++++++++++++-----------------
 4 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi
index 2b03399b0a7..d1766026db2 100644
--- a/doc/emacs/package.texi
+++ b/doc/emacs/package.texi
@@ -329,15 +329,15 @@ Package Installation
 @section Package Installation
 
 @findex package-install
-@findex package-update
-@findex package-update-all
+@findex package-upgrade
+@findex package-upgrade-all
   Packages are most conveniently installed using the package menu
 (@pxref{Package Menu}), but you can also use the command @kbd{M-x
 package-install}.  This prompts for the name of a package with the
 @samp{available} status, then downloads and installs it.  Similarly,
-if you want to update a package, you can use the @kbd{M-x
-package-update} command, and if you just want to update all the
-packages, you can use the @kbd{M-x package-update-all} command.
+if you want to upgrade a package, you can use the @kbd{M-x
+package-upgrade} command, and if you want to upgrade all the packages,
+you can use the @kbd{M-x package-upgrade-all} command.
 
 @cindex package requirements
   A package may @dfn{require} certain other packages to be installed,
@@ -551,8 +551,8 @@ Fetching Package Sources
 source code for a package directly from source.  The command will also
 automatically ensure that all files are byte-compiled and auto-loaded,
 just like with a regular package.  Packages installed this way behave
-just like any other package.  You can update them using
-@code{package-update} or @code{package-update-all} and delete them
+just like any other package.  You can upgrade them using
+@code{package-upgrade} or @code{package-upgrade-all} and delete them
 again using @code{package-delete}.  They are even displayed in the
 regular package listing.  If you just wish to clone the source of a
 package, without adding it to the package list, use
diff --git a/etc/NEWS b/etc/NEWS
index 1822ff17265..b6c9d9012b6 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1828,13 +1828,13 @@ this includes "binary" buffers like 'archive-mode' and 'image-mode'.
 ** Package
 
 +++
-*** New command 'package-update'.
+*** New command 'package-upgrade'.
 This command allows you to upgrade packages without using 'M-x
 list-packages'.
 
 +++
-*** New command 'package-update-all'.
-This command allows updating all packages without any queries.
+*** New command 'package-upgrade-all'.
+This command allows upgrading all packages without any queries.
 
 +++
 *** New commands 'package-recompile' and 'package-recompile-all'.
diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
index af57095f8ce..fa9fce24acc 100644
--- a/lisp/emacs-lisp/package-vc.el
+++ b/lisp/emacs-lisp/package-vc.el
@@ -24,7 +24,7 @@
 
 ;; While packages managed by package.el use tarballs for distributing
 ;; the source code, this extension allows for packages to be fetched
-;; and updated directly from a version control system.
+;; and upgraded directly from a version control system.
 ;;
 ;; To install a package from source use `package-vc-install'.  If you
 ;; aren't interested in activating a package, you can use
@@ -660,19 +660,19 @@ package-vc--read-package-desc
                #'string=)))
 
 ;;;###autoload
-(defun package-vc-update-all ()
-  "Attempt to update all installed VC packages."
+(defun package-vc-upgrade-all ()
+  "Attempt to upgrade all installed VC packages."
   (interactive)
   (dolist (package package-alist)
     (dolist (pkg-desc (cdr package))
       (when (package-vc-p pkg-desc)
-        (package-vc-update pkg-desc))))
-  (message "Done updating packages."))
+        (package-vc-upgrade pkg-desc))))
+  (message "Done upgrading packages."))
 
 ;;;###autoload
-(defun package-vc-update (pkg-desc)
-  "Attempt to update the package PKG-DESC."
-  (interactive (list (package-vc--read-package-desc "Update VC package: " t)))
+(defun package-vc-upgrade (pkg-desc)
+  "Attempt to upgrade the package PKG-DESC."
+  (interactive (list (package-vc--read-package-desc "Upgrade VC package: " t)))
   ;; HACK: To run `package-vc--unpack-1' after checking out the new
   ;; revision, we insert a hook into `vc-post-command-functions', and
   ;; remove it right after it ran.  To avoid running the hook multiple
@@ -870,7 +870,7 @@ package-vc-rebuild
 cookies, re-compiling Emacs Lisp files, building and installing
 any documentation, downloading any missing dependencies.  This
 command does not fetch new revisions from a remote server.  That
-is the responsibility of `package-vc-update'.  Interactively,
+is the responsibility of `package-vc-upgrade'.  Interactively,
 prompt for the name of the package to rebuild."
   (interactive (list (package-vc--read-package-desc "Rebuild package: " t)))
   (package-vc--unpack-1 pkg-desc (package-desc-dir pkg-desc)))
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index ffa6272dd1f..e15536c9f50 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2263,24 +2263,24 @@ package-install
           (message  "Package `%s' installed." name))
       (message "`%s' is already installed" name))))
 
-(declare-function package-vc-update "package-vc" (pkg))
+(declare-function package-vc-upgrade "package-vc" (pkg))
 
 ;;;###autoload
-(defun package-update (name)
-  "Update package NAME if a newer version exists."
+(defun package-upgrade (name)
+  "Upgrade package NAME if a newer version exists."
   (interactive
    (list (completing-read
-          "Update package: " (package--updateable-packages) nil t)))
+          "Upgrade package: " (package--upgradeable-packages) nil t)))
   (let* ((package (if (symbolp name)
                       name
                     (intern name)))
          (pkg-desc (cadr (assq package package-alist))))
     (if (package-vc-p pkg-desc)
-        (package-vc-update pkg-desc)
+        (package-vc-upgrade pkg-desc)
       (package-delete pkg-desc 'force)
       (package-install package 'dont-select))))
 
-(defun package--updateable-packages ()
+(defun package--upgradeable-packages ()
   ;; Initialize the package system to get the list of package
   ;; symbols for completion.
   (package--archives-initialize)
@@ -2298,23 +2298,23 @@ package--updateable-packages
     package-alist)))
 
 ;;;###autoload
-(defun package-update-all (&optional query)
+(defun package-upgrade-all (&optional query)
   "Refresh package list and upgrade all packages.
-If QUERY, ask the user before updating packages.  When called
+If QUERY, ask the user before upgrading packages.  When called
 interactively, QUERY is always true."
   (interactive (list (not noninteractive)))
   (package-refresh-contents)
-  (let ((updateable (package--updateable-packages)))
-    (if (not updateable)
-        (message "No packages to update")
+  (let ((upgradeable (package--upgradeable-packages)))
+    (if (not upgradeable)
+        (message "No packages to upgrade")
       (when (and query
                  (not (yes-or-no-p
-                       (if (length= updateable 1)
-                           "One package to update.  Do it? "
-                         (format "%s packages to update.  Do it?"
-                                 (length updateable))))))
-        (user-error "Updating aborted"))
-      (mapc #'package-update updateable))))
+                       (if (length= upgradeable 1)
+                           "One package to upgrade.  Do it? "
+                         (format "%s packages to upgrade.  Do it?"
+                                 (length upgradeable))))))
+        (user-error "Upgrade aborted"))
+      (mapc #'package-upgrade upgradeable))))
 
 (defun package--dependencies (pkg)
   "Return a list of all dependencies PKG has.
-- 
2.37.2

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Eli Zaretskii]

> Date: Mon, 24 Apr 2023 02:06:45 +0300
> From: Dmitry Gutov <dmitry@gutov.dev>
> Cc: adam@alphapapa.net, philipk@posteo.net, larsi@gnus.org,
>  62750@debbugs.gnu.org
> 
> Here's a couple of other existing functions:
> 
>    package--update-selected-packages
>    package--update-downloads-in-progress
> 
> Neither of these relate to upgrading packages. Although the former could 
> be easy to mistake for that now.
> 
> In all older functions, the term "update" (in comments and variable 
> names) refers to updating the value of some variable, not packages.
> 
> By analogy, 'M-x package-update-all' might be easy enough to mistake for 
> updating the list of packages available for installation, for example.
> 
> Here's a patch that does the rename. Also including package-vc-update* 
> that Philip mentioned.

Any objections to these renames, anyone?

Does anyone think we need to leave behind aliases for the old names?

Me, I have only one potential issue: since "update" just means "delete
the installed version, then install another version", it could be
easily made to downgrade, not just to upgrade.  So if we ever would
like to allow downgrading, the new names will get in the way.  But if
this is not an issue we should be bothered about, it's fine by me.

Thanks.

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Adam Porter]

On 4/24/23 07:02, Eli Zaretskii wrote:

> Me, I have only one potential issue: since "update" just means "delete
> the installed version, then install another version", it could be
> easily made to downgrade, not just to upgrade.  So if we ever would
> like to allow downgrading, the new names will get in the way.  But if
> this is not an issue we should be bothered about, it's fine by me.

IMHO, a command to downgrade ought to be a separate command with a 
different name--not only to reduce confusion, but because downgrading 
packages is an operation that is more likely to require manual user 
intervention, such as recompiling other packages that depend on the 
downgraded package (e.g. if struct or macro definitions change, or 
symbols disappear).

It's easy enough to cause that problem when upgrading, and much more 
likely when downgrading, to the extent that it's arguable that a command 
to downgrade shouldn't exist, because users who want to downgrade a 
package should be prepared to deal with the potential fallout.

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Dmitry Gutov]

On 24/04/2023 20:28, Adam Porter wrote:
> On 4/24/23 07:02, Eli Zaretskii wrote:
> 
>> Me, I have only one potential issue: since "update" just means "delete
>> the installed version, then install another version", it could be
>> easily made to downgrade, not just to upgrade.  So if we ever would
>> like to allow downgrading, the new names will get in the way.  But if
>> this is not an issue we should be bothered about, it's fine by me.
> 
> IMHO, a command to downgrade ought to be a separate command with a 
> different name--not only to reduce confusion, but because downgrading 
> packages is an operation that is more likely to require manual user 
> intervention, such as recompiling other packages that depend on the 
> downgraded package (e.g. if struct or macro definitions change, or 
> symbols disappear).

That might also be the case when upgrading a package that some others 
depend on (newer version could also have macros deleted or renamed).

Either way, though, we could make it a separate command.

Or even augment the current one: (package-upgrade 'name 
"some-older-version") has a similar feel to (forward-char -1), not 
exactly unfamiliar to us.

Would "update" be a more proper term to cover both upgrading and 
downgrading? I'm not sure about that. Aside from "downgrade", I would 
probably say "revert" or "install an older version". E.g. when using 
apt-get, the relevant subcommand would be "install".

> It's easy enough to cause that problem when upgrading, and much more 
> likely when downgrading, to the extent that it's arguable that a command 
> to downgrade shouldn't exist, because users who want to downgrade a 
> package should be prepared to deal with the potential fallout.

Or that. We don't keep older versions around in ELPA anyway, so for now 
the question is moot.

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Eli Zaretskii]

> Date: Mon, 24 Apr 2023 21:54:58 +0300
> Cc: monnier@iro.umontreal.ca, philipk@posteo.net, larsi@gnus.org,
>  62750@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 24/04/2023 20:28, Adam Porter wrote:
> > On 4/24/23 07:02, Eli Zaretskii wrote:
> > 
> >> Me, I have only one potential issue: since "update" just means "delete
> >> the installed version, then install another version", it could be
> >> easily made to downgrade, not just to upgrade.  So if we ever would
> >> like to allow downgrading, the new names will get in the way.  But if
> >> this is not an issue we should be bothered about, it's fine by me.
> > 
> > IMHO, a command to downgrade ought to be a separate command with a 
> > different name--not only to reduce confusion, but because downgrading 
> > packages is an operation that is more likely to require manual user 
> > intervention, such as recompiling other packages that depend on the 
> > downgraded package (e.g. if struct or macro definitions change, or 
> > symbols disappear).
> 
> That might also be the case when upgrading a package that some others 
> depend on (newer version could also have macros deleted or renamed).
> 
> Either way, though, we could make it a separate command.

A separate command that does the same, or almost the same, as
package-upgrade?  That's uneconomical, let alone elegant.

> Or even augment the current one: (package-upgrade 'name 
> "some-older-version") has a similar feel to (forward-char -1), not 
> exactly unfamiliar to us.

We are talking about invoking commands, not about Lisp programs.  How
many times did you do "C-- C-f" instead of "C-b"?

> We don't keep older versions around in ELPA anyway, so for now the
> question is moot.

I was trying to raise a possible future issue.  We all know that
command names, once they gain enough tenure, cannot be easily changed.
So this is the time to think about future issues; we won't have
another chance.  It's exactly why we should consider what is today a
"moot point" but could be a real one later.

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Dmitry Gutov]

On 24/04/2023 22:13, Eli Zaretskii wrote:
>> Or even augment the current one: (package-upgrade 'name
>> "some-older-version") has a similar feel to (forward-char -1), not
>> exactly unfamiliar to us.
> We are talking about invoking commands, not about Lisp programs.  How
> many times did you do "C-- C-f" instead of "C-b"?

Considering one would have to enter a specific version to downgrade to 
(right?), they'd have to do it interactively. Unlike in the case of 
upgrading, where we almost always want the most recent version.

If one had to explicitly input the number of chars to go forward anyway, 
we would have little use for backward-char.

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Dmitry Gutov]

On 10/04/2023 15:53, Adam Porter wrote:
> But, IMHO, these commands should be named 'package-upgrade' and
> 'package-upgrade-all'.

They have now been renamed (with Eli's blessing in another bug's 
thread). Without compatibility aliases.

Functions inside package-vc.el have been renamed too.

Thanks everybody! Closing.

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Philip Kaludercic]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 10/04/2023 15:53, Adam Porter wrote:
>> But, IMHO, these commands should be named 'package-upgrade' and
>> 'package-upgrade-all'.
>
> They have now been renamed (with Eli's blessing in another bug's
> thread). Without compatibility aliases.
>
> Functions inside package-vc.el have been renamed too.

Thanks for that.

> Thanks everybody! Closing.

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> That might also be the case when upgrading a package that some others
> depend on (newer version could also have macros deleted or renamed).

We try to make upgrades "safe", but there's usually no such effort the
other way around, so downgrading is definitely more risky in practice,
even though in theory things can break in all cases.

> Would "update" be a more proper term to cover both upgrading and
> downgrading?

I think if you specify the target version, then `package-install` sounds
about right (and I suspect it may already "work").

> Or that.  We don't keep older versions around in ELPA anyway, so for
> now the question is moot.

Well, we do keep them some `elpa.gnu.org` but indeed the ELPA protocol
doesn't include any way to advertise them.


        Stefan

bug#62750: 29.0.50; Commands 'package-update' and 'package-update-all' should be called '*-upgrade'

[Dmitry Gutov]

On 01/05/2023 04:55, Stefan Monnier wrote:
>> That might also be the case when upgrading a package that some others
>> depend on (newer version could also have macros deleted or renamed).
> 
> We try to make upgrades "safe", but there's usually no such effort the
> other way around, so downgrading is definitely more risky in practice,
> even though in theory things can break in all cases.

Very true.

>> Would "update" be a more proper term to cover both upgrading and
>> downgrading?
> 
> I think if you specify the target version, then `package-install` sounds
> about right (and I suspect it may already "work").

It indeed "works" in the sense that package-install performs two 
different functions

- "Install package xyz" (i.e. make sure it is installed, some version),
- "Install xyz version 1.2.3 (installs that version)

It doesn't delete the currently installed version in the latter case 
either, though, and when  downgrading we'll almost certainly want that 
to happen.