305261 - Automatic update says it finds an update to Deer Park 1.0+ when it's really 1.6a1 / 1.4

Status: RESOLVED WORKSFORME

(Toolkit :: Application Update, defect)

Description

[Dave Townsend [:mossop]]

The trunk firefox is on version 1.6a1. Running check for updates says it finds
an update to "Deer Park 1.0+". Downloading and installing and the version is
actually 1.6a1.

Comment 1

[Dave Townsend [:mossop]]

This appears to be fixed now.

Comment 2

[Chase Phillips]

Wasn't cc'd on this so I didn't know it existed.  This was/is an artifact of how
the update info is currently sent from the build systems.  If we get time we'll
address it sooner rather than later.  Until we address it, version bumps need to
be accompanied by similar changes to the build systems.

Comment 3

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050918
Firefox/1.4 ID:2005091812

the update window tell me there's an update for 1.0+

Comment 4

[Chase Phillips]

(In reply to comment #3)
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050918
> Firefox/1.4 ID:2005091812
> 
> the update window tell me there's an update for 1.0+

Still working out why, but it appears that if you update in the first 15-30
minutes after a complete update has been made available, you get a message that
1.0+ is what you're updating to.  Everything works properly after the partial
patch is written.  Will investigate.

Comment 5

[Peter van der Woude [:Peter6]]

(In reply to comment #4)

> Still working out why, but it appears that if you update in the first 15-30
> minutes after a complete update has been made available, you get a message that
> 1.0+ is what you're updating to.  Everything works properly after the partial
> patch is written.  Will investigate.

Yep, it's fine now Chase

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20050921
Firefox/1.4 ID:2005092107

resolving

Comment 6

[Peter van der Woude [:Peter6]]

duh...
I thing i found the issue now:

If I update from a nightly build , say 2005092207 to the 2005092308 nightly
build, everything works fine and the update is reported as 1.4

If I update from an hourly build, say 2005092209 to the 2005092308 nightly
build, Murphy kicks in, the update is reported as 1.0+ and it mdared to tell me
it was going to disable a fully compatible extension (Consol²).
(screenshot follows)

Given the fact that non-testers do download hourly builds, just to get a
"release build" before anyone else (thanks to pre announcements on e.g. /. and
others) this should be fixed before 1.5 final.

(better avoid than deal with 10.000 dupe crap bugs later)

Comment 7

[Peter van der Woude [:Peter6]]

Attachment: update dialog hourly->nightly

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20050923
Firefox/1.4 ID:2005092307

Comment 8

[Robert Strong (they/them - no direct email)]

Peter - just to verify, it didn't disable the extension though it said it
would... true?

Comment 9

[Peter van der Woude [:Peter6]]

(In reply to comment #8)
> Peter - just to verify, it didn't disable the extension though it said it
> would... true?

Lemme try that Robert (but let's back up my profile first)

Comment 10

[Peter van der Woude [:Peter6]]

(In reply to comment #9)
> > Peter - just to verify, it didn't disable the extension though it said it
> > would... true?
Nope, the extension(s) work fine, it's just the confusing message (and ugly
looking warning).

Comment 11

[Sebastian P. Goetze]

To confirm: 

I had the exact same behaviour that Peter had (almost the same picture as in the
attachment), BUT updating nightly -> nightly.

(now Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20050925
Firefox/1.4 - Build ID: 2005092506)

Supposedly 2 extensions incompatible (Console² and Classic Menus) and to be
disabled, but still alive and well after the update (i.e. NOT disabled).

Comment 12

[Robert Strong (they/them - no direct email)]

URL using a nightly build - everything is correct
https://aus2.mozilla.org/update/1/Firefox/1.4/2005092205/Linux_x86-gcc3/en-US/nightly/update.xml

URL with the last digit in the build id decremented
https://aus2.mozilla.org/update/1/Firefox/1.4/2005092204/Linux_x86-gcc3/en-US/nightly/update.xml

Notice that
version="1.0+"
extensionVersion="1.0+"

Comment 13

[Dave Townsend [:mossop]]

This could be related some oddity I came across the other day with incremental
updating. I don't recall the specifics but it came down to a problem when the
build starts shortly before the end of an hour. The build id is generated fairly
early in the process, but the upload to the server happens in the next hour, so
a build in the server dir 2005-09-26-07 might actually contain build 2005092606.

Comment 14

[Magnus Melin [:mkmelin]]

I'm not *entirely* sure this is the same but...

This happened to me today with Thunderbird. I got notice about Thunderbird 1.0+
instead of Thunderbird 1.4 when I wanted to update from 20050928 to 29 branch.
It re-downloaded the whole thing (no incr.) but Thunderbird was not updated. Did
it twice but still the 20050928 version stayed. Linux btw.

Comment 15

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 16

[:Gavin Sharp [email: [e-mail]]]

So this seems like a case of AUS not recognizing the build ID and then spitting
out the same <update type="minor" version="1.0+" extensionVersion="1.0+"> all
the time, even though the rest is correct (branch/trunk, latest build, full
download).

Comment 17

[Michael Morgan [:morgamic]]

Examining and testing AUS2 behavior when partial/complete patch data exists without the other.  The solution is most likely not offering a partial update when a complete update doesn't exist.  Will have to delve into things a bit deeper to find out why things get skewed when a complete exists on its own.

The 1.0+ issue comes form AUS2 defaults that get chosen when the complete patch data doesn't exist.  This will be resolved once the presence of a complete patch is a prerequisite for offering an update.

Thanks for all the great feedback - nice catch everyone.

Comment 18

[Nick Thomas [:nthomas] (UTC+12)]

I can't reproduce this bug anymore. Starting immediately after the Firefox 20051107 branch nightly was produced, I pulled update.xml [1] with wget every 30 seconds. The content of the file went from <updates></updates>, to one with partial & complete patches and a version of 1.5. Whatever change caused bug 314189 might be related, if it disabled complete patches in the absence of a partial one.

[1] https://aus2.mozilla.org/update/1/Firefox/1.5/2005110503/WINNT_x86-msvc/en-US/nightly/update.xml

Comment 19

[Andreas Morawietz]

Bug could be closed, or not?

Comment 20

[Nick Thomas [:nthomas] (UTC+12)]

Trunk is now at 3.0a1 and there aren't problems with updates being mislabeled.