262688 - bump version numbers for 1.0 RC1, RC2 and Final.

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect, P1)

Description

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041003
Firefox/0.10

did update with xpi yesterday bumping version to 0.10.1
After installing todays sweetlou it's back to 0.10 and wants to install the
critical update again

Comment 1

[Mike Pesce (:By-Tor)]

Shouldn't the nightlies be 0.10.1+?  Or would that cause more confusion?

Comment 2

[u88484]

I really feel this needs to happen because a lot of confusing people on the
mozillazine forums asking if or why dont the nightlys have the security updates.

Comment 3

[Peter van der Woude [:Peter6]]

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

Comment 4

[u88484]

i know i'm not supposed to aprrove blocking flags...but this one is common
sense. the nightly versioning number has no affect on blocking of a release.

Comment 5

[u88484]

i know i'm not supposed to mess with blocking flags...but this one is common
sense. the nightly versioning number has no affect on blocking of a release.

blocking-aviary1.0 denied

Comment 6

[Asa Dotzler [:asa]]

Kurt, please don't set the plus or minus on flags. Thanks.

Comment 7

[sairuh (rarely reading bugmail)]

I can understand not fixing this for nightlies, but I'm not sure if the
app.version will be automatically bumped up (to 0.10.1, 0.10.1+, or whichever)
with release builds such as RC1 (and RC2 if that occurs) and 1.0final. if
app.version does get incremented for release builds, then I could understand
minusing this bug.

Comment 8

[Peter van der Woude [:Peter6]]

(In reply to comment #7)
> I can understand not fixing this for nightlies, but I'm not sure if the
> app.version will be automatically bumped up (to 0.10.1, 0.10.1+, or whichever)
> with release builds such as RC1 (and RC2 if that occurs) and 1.0final. if
> app.version does get incremented for release builds, then I could understand
> minusing this bug.
Try a nighly build and get the same update message every day.
This is extremely confusing for traumatised ex-IE users ;-)

Comment 9

[Ronny Perinke]

Attachment: patches version.txt and firefox.js

browser/config/version.txt contains the version
browser/app/profile/firefox.js needs to be patched to display the correct
version in useragent string

Comment 10

[jayfromtaiwan]

But by doing this most of the extensions would stop working, again. (because of
the hard-coded version number)

Comment 11

[Peter van der Woude [:Peter6]]

they all work if you apply the security patch.xpi too

Comment 12

[sairuh (rarely reading bugmail)]

(In reply to comment #10)
> But by doing this most of the extensions would stop working, again. (because of
> the hard-coded version number)

as Peter mentioned in comment 11, this shouldn't be a problem: the product
version (the pref app.version) differs from the app.extensions.version. fixing
this bug would increment app.version, but not app.extensions.version --the
latter would only be incremented (iirc) for release builds. (Ben or Chase, if
this is incorrect, do let us know --thanks!)

Comment 13

[Ronny Perinke]

(In reply to comment #12)
> (In reply to comment #10)
> > But by doing this most of the extensions would stop working, again. 
(because of
> > the hard-coded version number)
> as Peter mentioned in comment 11, this shouldn't be a problem: the product
> version (the pref app.version) differs from the app.extensions.version. fixing
> this bug would increment app.version, but not app.extensions.version --the
> latter would only be incremented (iirc) for release builds. (Ben or Chase, if
> this is incorrect, do let us know --thanks!)

Right (i hope so), the patch does not change app.extensions.version it will 
only update app.version, because version.txt gets updated.
And to display the new app version within the useragent, the value for 
general.useragent.vendorSub will assigned exactly the same way like the value 
of app.version.

It will be the same like in the official 0.10.1 release.

Comment 14

[Chase Phillips]

This is the right thing to do and the patch looks correct to me.  I discussed
this with Ben and we've agreed to hold on making this version change until just
before the Firefox 1.0 RC1 release, currently scheduled for 10/18.

Based on feedback from Ben, making this bug blocking-aviary1.0+ to ensure it
stays on his radar for the upcoming release.

Comment 15

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

Attachment: patch

cover all cases.

Comment 16

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

Attachment: RC1 patch - landed

make sure about dialog looks correct, and UA value is correct

Comment 17

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

we will need two more patches here - one to change strings to RC2 for RC2, and
one to remove the RC# strings after RC2. 

Comment 18

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

Attachment: RC2 patch

to be landed prior to RC2

Comment 19

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

Attachment: RTM patch

to be landed prior to 1.0 rtm.

Comment 20

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

Attachment: RTM patch

to be landed prior to 1.0 rtm.

Comment 21

[Steffen Wilberg]

Ben, the pref app.version is now set to 1.0, which effectively disables Software
Update. RC1 users won't get a notification when RC2 or RTM is released because
their build thinks it is 1.0 already.

We need to set app.version in firefox.js explicitly.

Comment 22

[David Janes]

I completely agree with Comment 21 - if a user downloads RC 1 then they won't be
prompted to upgrade until post 1.0 final!

It should be changed to something different so that the auto-update still works!

Comment 23

[Uri Bernstein]

What about the OS X release? If I understood correctly the OS X release which
will coincide with 1.0 for Linux and Windows will NOT be called "1.0" (it's
called "0.11" in the roadmap, but that's probably not the official name).
The patches attached, as far as I can see, make no special exception for OS X,
so the OS X release will (incorrectly) be labled "1.0".

Or am I missing anything?

Comment 24

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

1) We're not going to splash the RCs
2) The RCs are about a week apart
3) The RCs are about a week or so from 1.0 final

We are coordinating a message to send to testers so that it is clear that the RC
builds precede the final release by only a couple of weeks, and as such they
should be on the ball to update the builds themselves. Everyone else should wait
a few weeks for 1.0f. 

Comment 25

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

Attachment: final rc1 changes to adjust version number

Comment 26

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

Attachment: final rc2 changes to adjust version number - landed, plus change to firefox.js

Comment 27

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

(In reply to comment #25)
> Created an attachment (id=163482)
> final rc1 changes to adjust version number
> 

Checked in. 

Comment 28

[Jon Granrose]

we need to figure out what the version number / profile migration interaction is
before we update version numbers again.

also, we've typically used milestones as version numbers 0.9, 0.10, 0.11.  Could
we use 0.11.1 0.11.2 0.11.3 for 1.0rc1 rc2 and final?  Then a 1.0.1 could either
be 1.0.1 or 0.11.4?

Comment 29

[Michael Lefevre]

for the record, Ben checked in the patch to bump the numbers to RC2 (at
2004-10-29 14:16 bonsai time), but left version numbers unaltered as with RC1

Comment 30

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

one final patch needed to remove the RC flags. 

Comment 31

[Peter van der Woude [:Peter6]]

Make sure to bump trunk ver to 1.0+ or whatever right after the final bump on
branch.
Extension with minVersion="1.0" fail on 0.9.3+

Comment 32

[Asa Dotzler [:asa]]

Now that RC2 has shipped, we can probably bump this any time.

Comment 33

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

Attachment: patch

Comment 34

[Tracy Walker [:tracy]]

Verified with Firefox branch builds:
Win 2004-11-05-07-0.11
Mac 2004-11-05-06-0.11