302062 - Comprehensive Log of Updates

Status: RESOLVED FIXED

(Toolkit :: Application Update, enhancement)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

Currently the Update History UI only shows version transition updates... it'd be
nice to have a text changelog of all updates applied, no matter whether or not
the version number changes... so we can easily diagnose problems updating across
nightly builds for example.

Comment 1

[Mike Mason]

This sounds like a great idea.
Can you tell me what a "version transition update" means?

What would have to change in this build to be considered one?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050726
Firefox/1.0+ ID:2005072606

or To be more spe specific would it be in the string that is evaluated in
app.update.url?
https://aus-staging.mozilla.org:8711/update2/0/Firefox/1.0+/2005072606/WINNT_x86-msvc/en-US/update.xml

Comment 2

[Darin Fisher]

"version transition update" means a change from version 1.1 to 1.2, for example.
 The version of the trunk, development version of firefox is 1.0+, and that
doesn't change from nightly build to nightly build.  as a result, when you
update firefox from one nightly to the next, it does not record it in the update
history UI.

Comment 3

[Darin Fisher]

*** Bug 301980 has been marked as a duplicate of this bug. ***

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

client side parts of this fix (requires upgrades to aus) also fixes 301622
(client side parts)

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 191382 [details] [diff] [review]
patch

also this patch improves the documentation in nsIUpdateService.idl

Comment 6

[Darin Fisher]

Comment on attachment 191382 [details] [diff] [review]
patch

>Index: toolkit/mozapps/update/public/nsIUpdateService.idl

> [scriptable, uuid(bd75a4c6-b813-45b2-a96e-41a429c857c4)]
> interface nsIUpdate : nsISupports

just for kicks, can you bump the UUID of this interface since
some attributes were added.


r=darin

Comment 7

[Kevin Brosnan]

*** Bug 306540 has been marked as a duplicate of this bug. ***

Comment 8

[Sebastian P. Goetze]

While you're at it...

Would it make sense to change the button from 'Cancel' to 'OK' ?

I mean - you're not canceling anything, are you? 
More like 'OK', that was the Update History...

The rest, like filling 'Installed on...' the Details URL and so on, depend on
the backend, I guess... (per comment #4)

Comment 9

[Chris Blore]

*** Bug 306677 has been marked as a duplicate of this bug. ***

Comment 10

[Kevin Brosnan]

*** Bug 307623 has been marked as a duplicate of this bug. ***

Comment 11

[Magnus Melin [:mkmelin]]

Reopening since this isn't working (which also the dupes filed after fixing
indicate). 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050917 Firefox/1.4

Comment 12

[Darin Fisher]

Yup, I agree.  It is not working (at least not in the 20050916 1.8-branch build
that has been updated numerous times).  Ben?

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

1. Normalizes names used by the client for the |type| field on the update
object to use the same values used by AUS ("major" and "minor" vs. "security"
and "normal"). Updates the strings file and the client code that uses the
strings file to prevent a js error. 

2. Makes the Update object correctly serialize its "buildID" property

3. Make sure the right Update object is added to the updates list in the Update
Manager so that multiple entries can show up.

Comment 14

[Darin Fisher]

Comment on attachment 196957 [details] [diff] [review]
patch

Looks Good. r=darin

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

landed on the branch, landing on the trunk once my trunk tree updates...

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

landed on the trunk too!

for nightlies to be differentiated, the server work in 309506 will have to be
done, but the client portions are now complete. 

Comment 17

[Axel Hecht [:Pike]]

Could someone tell me why we're lighting all l10n trees just to rename the 
property keys, but not their values?