636190 - Change firefox version on mozilla-central to 4.2a1pre

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P3)

Description

[LegNeato]

(not sure if we do this or not, apologies if it has been discussed elsewhere)

As of last night we branched for the (hopefully) final 4.0 beta. The automated version bump (http://hg.mozilla.org/mozilla-central/rev/67ee5b40edd5) makes nightlies 2.0b13pre.

This seems less than ideal as we aren't planning to have a beta 13. Should we bump it to 2.0pre (or whatever is used for a major)? What happens if we find issues that necessitates a beta 13?

Comment 1

[[e-mail] (:bhearsum)]

We should be able to safely bump to 2.0pre now. If we do a b13 the release automation will bump the relbranch version down to "2.0b13".

We can bump the nightly version backwards, though -- nightly users won't receive updates if we do. So, once the nightly version is 2.0pre, it needs to stay that way until 2.0.1pre.

Comment 2

[LegNeato]

Ok, I think we want to do this but hold off on doing this until beltzner weighs in.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm trying to remember when we did this in the past; I'm not sure there's any particular rush until we're ready to build an RC, is there?

The risk-averse part of me wants to hold off on this until we're closer to being sure that no late breaking blockers pop up that will require additional beta feedback. I bet we can make that decision on Monday next, if we want to put a deadline on it.

Comment 4

[Mike Shaver (:shaver emeritus)]

I agree -- I think it should be b13pre or b99pre until we relbranch for RC, at which point it becomes 2.0.1pre on the branch and ... something on the trunk.  I forget how we do RC-to-RC update mechanics, where the app reports the same 4.0 version on both?  Some build1/build2 chicanery?

Comment 5

[Sheila Mooney]

So we would leave it as Beta12pre until next Monday then decide? I had just asked Christian about this since after we cut the beta we normally make a change in crash stats (and other places) to point to whatever the next thing is ie: Beta13pre. I just want to make sure we are indeed looking at stats on the trunk, regardless of what we call it.

Comment 6

[LegNeato]

We can promote any build we want in the crash-stats UI. We shouldn't do b12pre because, well, it's more b12post and we want that data separate.

Note that there should be minimal b13pre users as long as we keep the nightlies frozen (I think, not sure which changeset we ended up freezing on...if it was before or after the version bump).

I'm fine leaving it as-is. I just noticed previously there were news articles written about "preparing another beta" when we switched nightly versions, and this time there isn't another.

Comment 7

[[e-mail] (:bhearsum)]

(In reply to comment #4)
> which point it becomes 2.0.1pre on the branch and ... something on the trunk. 

2.1a1pre? We can bump it higher later.

> I forget how we do RC-to-RC update mechanics, where the app reports the same
> 4.0 version on both?  Some build1/build2 chicanery?

Release Automation considers RC1 and RC2 different releases as everything except the in-app version goes (that is: FTP directories, updates, tags on repositories, et. al), so the standard update mechanisms are used.

--

Based on the rest of this bug it sounds like there's no action at this time, and we can keep this bug open as a placeholder.

Comment 8

[pal-moz]

Branch (mozilla-2.0) should/will be 2.0pre/4.0pre
and
Trunk (mozilla-central) should be 2.1a1pre/4.1a1pre or 2.5a1pre/4.5a1pre 
?

when 1.9.2(Firefox 3.6) Branch was built, Trunk changed from 1.9.2a2pre/3.6a2pre to 1.9.3a1pre/3.7a1pre.
Branch use 1.9.2a2pre/3.6a2pre.
http://hg.mozilla.org/mozilla-central/rev/6fa9e4164629

Comment 9

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

The point we branch is separate, but I'm sure we'd appreciate an indication of when that might happen.

Comment 10

[Aki Sasaki (not active)]

(In reply to comment #8)
> Branch (mozilla-2.0) should/will be 2.0pre/4.0pre
> and
> Trunk (mozilla-central) should be 2.1a1pre/4.1a1pre or 2.5a1pre/4.5a1pre 
> ?

2.1 is now earmarked for Fennec 4.0[.x], so I would say trunk's minimum milestone should be 2.2a1pre.  Whether that means 2.2a1pre or 2.5a1pre or 3.0a1pre is someone else's call.

Comment 11

[Justin Wood (:Callek)]

see-also: Bug 644011, we bumped the milestone tonight; still have to do the main Firefox version.

Comment 12

[Chris AtLee [:catlee]]

Attachment: Bump firefox version to 4.2a1pre

Comment 13

[Chris AtLee [:catlee]]

Attachment: Set up 4.2* nightly channel support in AUS

Comment 14

[[e-mail] (:bhearsum)]

Comment on attachment 521158 [details] [diff] [review]
Set up 4.2* nightly channel support in AUS

Need to change 4.0 to point at "mozilla-2.0", too, and you can probably drop tracemonkey/electrolysis from the 4.0 version.

Comment 15

[Chris AtLee [:catlee]]

Attachment: Set up 4.2* nightly channel support in AUS

bsmedberg points out we should keep 4.0 users on mozilla-central for now

Comment 16

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

Comment on attachment 521163 [details] [diff] [review]
Set up 4.2* nightly channel support in AUS

>Index: inc/config-dist.php
>     'Firefox'     =>  array(
>         '2.0*'    =>  '2.0',
>         '3.0*'   =>  'trunk',
>-        '3.1*'    => 'mozilla-1.9.1',
>         '3.5*'    => 'mozilla-1.9.1',
>         '3.6*plugin*' => 'firefox-lorentz',
>         '3.6*'    => 'mozilla-1.9.2',

If we're cleaning up, then 2.0*, 3.0* and 3.6*plugin* can also go. First two we're not doing nightlies for, and we have no plugin nightly users.

>-        '3.2*'    => 'mozilla-central',
>-        '3.7*'    => array(

Still 2.4k people on 3.7*pre (yesterday, by AUS pings), almost all of them on the nightly channel. Please add back in a line
        '3.7*'    => 'mozilla-central',

>+        // TODO: 4.0 should point to mozilla-2.0 eventually
>+        // 4.0* tracemonkey and electrolysis can go away too at that point
>+        '4.0*'    => array(

They can go away if tracemonkey has merged the version bump, and we've had enough days that there aren't many users with 4.0b13pre left. We strand them otherwise. Less than 10 people on electrolysis.

r+ with the suggestions.

Comment 17

[Rick Stockton]

OT PROBLEM:

I am unable to install add-ons which I regard as "critical" (e.g., NoScript) even after setting the binary prefs "extensions.checkCompatibility.4.2a" with the value "false", and the general "extensions.checkCompatibility" also set to "false". The "Add on compatibility checking is disabled..." message DOES appear at the top of the Add-ons "extensions" panel, but I still get the

"blah-blah-blah is incompatible with Minefield 4.2a1pre"

Message AFTER I have been allowed to install the extension (into that "holding directory) via the Prefence. But once I restart, the extension comes up with the incompatible marking.

How should I allow extensions to become active, without editing and rebuilding the entire xpi? Or should I just give up on the Nightly Channel, because I'm not smart enough to stay here?

Comment 18

[Chris AtLee [:catlee]]

Attachment: Once more, with feeling

Comment 19

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

Comment on attachment 521334 [details] [diff] [review]
Once more, with feeling

Patch for another bug.

Comment 20

[Chris AtLee [:catlee]]

Attachment: Once more, with moar feeling

Comment 21

[Chris AtLee [:catlee]]

Comment on attachment 521336 [details] [diff] [review]
Once more, with moar feeling

Checking in inc/config-dist.php;
/cvsroot/mozilla/webtools/aus/xml/inc/config-dist.php,v  <--  config-dist.php
new revision: 1.125; previous revision: 1.124
done

Comment 22

[Ed Lee :Mardak]

(In reply to comment #17)
> even after setting the binary prefs "extensions.checkCompatibility.4.2a"
That's the correct preference that should be set to false. And it works for me.

> once I restart, the extension comes up with the incompatible marking
The add-on is still active even with the marking. It's just reminding that it's not been tested/updated for the version you're on.

Comment 23

[aja+bugzilla]

(In reply to comment #22)
> (In reply to comment #17)
> > even after setting the binary prefs "extensions.checkCompatibility.4.2a"
> That's the correct preference that should be set to false. And it works for me.
> 
> > once I restart, the extension comes up with the incompatible marking
> The add-on is still active even with the marking. It's just reminding that it's
> not been tested/updated for the version you're on.

Add-on Compatibility Reporter has been updated to 0.8.2...and seems to work fine.