RE: Should Emacs have an upgrade procedure?

["Drew Adams" <drew.adams@oracle.com>]

> Should Emacs have an upgrade procedure?
> 
> Here's a user story:
> - The user has just installed Emacs 24, previously having running
>   Emacs23
> - The Emacs splash screen shows a message: "A number of defaults have
>   been changed between Emacs 23 and 24. Would you like to go 
>   through the changes, or just enable them?". This message is NOT
>   shown if the user previously had expressed an opinion about
>   these particular defaults.
> 
> OK, you get the picture I suppose. Good or bad? There are elisp
> libraries out there that already implements this of course.

Good or bad? Good.

That is, some additional, better way to do these two things would be welcome:

1. Let users know about such changes (including also new features, not just
changes in defaults).

NEWS is what it is - necessary, probably, but not ideal as a user aid. An
additional way to present the change info would be welcome. NEWS is somewhat
implementation-centric or development-centric. A top-level user-centric view
would be a helpful addition.

2. Let users make at least an initial decision about acceptance of such changes.
On a group basis and on an individual-change basis.


Dunno about particular ways to do #1 and #2 (including the scenario you
suggest), but I agree about the basic idea. In general terms, these would help,
IMO:

1. Some kind of tour of the changes and their impact for users. This is an
education thing, a means to give users an idea whether they might want to
accept/enable such-and-such change or not. This could be Web-based, esp. if
local resources are a problem.

2. Some kind of easy dialog to let them opt in/out for individual changes, and
for large groups of changes at once, and even for all changes.

#2 could be done using an organized dialog box (groups of check boxes, for
example). Or something else could be devised. (A "wizard-like" long sequence of
"Do you want X?" is a no-no, IMO.)

3. Each change demo'd or illustrated in #1 should be a choice in #2, and vice
versa. The choice dialog of #2 could even have individual links to the
corresponding illustrations in #1 - education is also about reminding. And vice
versa: in the tour presentation of a particular change, there could be a link to
the part of #2 that lets you choose.

4. It should be easy to (a) skip #2 altogether and (b) do #2 later, at any time
(including redoing it, changing one's mind). Obviously, it should also be easy
to skip #1. Users should not have to hunt later to find how to (re)do #1 and #2.
Two places we could provide quick links to #1 and #2: the Help menu and the
splash page.

5. It would be good for a user to be able to do #1 and #2 for past releases as
well.

This would require, at the least, having a way to identify internally each
user-visible change for a given release (or at least those deemed important
enough to figure in #1 and #2).


Do I expect that this will really happen anytime soon, given our limited dev
resources (not to mention our difficulties to agree, especially about UI)? No.
But identifying and agreeing on the goal is one step, and some baby steps toward
realizing it could perhaps be accomplished.

So yes, I think the question you raise is a good one, and your proposal is a
reasonable one to consider.

(I wouldn't characterize this as being about an "upgrade procedure", however.
It's more about (a) educating users about changes and (b) facilitating their
control over those changes.)