Re: Should Emacs have an upgrade procedure?

[joakim]

"Drew Adams" <address@hidden> writes:

>> 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.

Good!

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

I try to adress your concerns below from the perspective of the subject
"Should Emacs have an upgrade procedure?". This doesnt mean I reject
your thoughts. 

> 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.

This isnt within the scope of the proposal.

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

This is handled well by an upgrade procedure I think.

>
> 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.

The "upgrade process" proposal doesnt try to cover this.

> 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.

Yes.

> #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.)

I agree.

>
> 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.

Rollback is within the scope of upgrade handling I think.

>
> 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).

Maybe this could be realized as flags to defcustom?

>
> 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.)

This particular thread was about finding out if a strictly scoped
upgrade process could maybe help with solving, lets say, 80% of the
concerns you rise.

-- 
Joakim Verona