Last Comment Bug 636190 - Change firefox version on mozilla-central to 4.2a1pre
: Change firefox version on mozilla-central to 4.2a1pre
Status: RESOLVED FIXED
[releases][inform metrics]
:
Product: Release Engineering
Classification: Other
Component: Other (show other bugs)
: other
: All All
: P3 major (vote)
: ---
Assigned To: Chris AtLee [:catlee]
:
:
Mentors:
Depends on: 644384
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-23 09:58 PST by christian
Modified: 2013-08-12 21:54 PDT (History)
25 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Bump firefox version to 4.2a1pre (172 bytes, patch)
2011-03-23 05:58 PDT, Chris AtLee [:catlee]
benjamin: review+
bhearsum: review+
Details | Diff | Splinter Review
Set up 4.2* nightly channel support in AUS (895 bytes, patch)
2011-03-23 06:02 PDT, Chris AtLee [:catlee]
no flags Details | Diff | Splinter Review
Set up 4.2* nightly channel support in AUS (1.22 KB, patch)
2011-03-23 06:25 PDT, Chris AtLee [:catlee]
bhearsum: review+
nthomas: review+
Details | Diff | Splinter Review
Once more, with feeling (4.72 KB, patch)
2011-03-23 15:35 PDT, Chris AtLee [:catlee]
no flags Details | Diff | Splinter Review
Once more, with moar feeling (1.33 KB, patch)
2011-03-23 15:38 PDT, Chris AtLee [:catlee]
nthomas: review+
catlee: checked‑in+
Details | Diff | Splinter Review

Description christian 2011-02-23 09:58:43 PST
(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 Ben Hearsum (:bhearsum) 2011-02-23 10:01:36 PST
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 christian 2011-02-23 11:30:41 PST
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] 2011-02-23 13:59:25 PST
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 -- probably not reading bugmail closely) 2011-02-23 16:23:05 PST
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 2011-02-23 17:40:51 PST
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 christian 2011-02-23 17:52:14 PST
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 Ben Hearsum (:bhearsum) 2011-02-24 05:23:52 PST
(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 2011-02-25 23:04:59 PST
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] 2011-02-28 12:54:02 PST
The point we branch is separate, but I'm sure we'd appreciate an indication of when that might happen.
Comment 10 Aki Sasaki [:aki] 2011-03-10 13:23:53 PST
(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) 2011-03-22 23:06:46 PDT
see-also: Bug 644011, we bumped the milestone tonight; still have to do the main Firefox version.
Comment 12 Chris AtLee [:catlee] 2011-03-23 05:58:09 PDT
Created attachment 521157 [details] [diff] [review]
Bump firefox version to 4.2a1pre
Comment 13 Chris AtLee [:catlee] 2011-03-23 06:02:33 PDT
Created attachment 521158 [details] [diff] [review]
Set up 4.2* nightly channel support in AUS
Comment 14 Ben Hearsum (:bhearsum) 2011-03-23 06:05:54 PDT
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] 2011-03-23 06:25:20 PDT
Created attachment 521163 [details] [diff] [review]
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] 2011-03-23 14:22:06 PDT
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 2011-03-23 15:31:41 PDT
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] 2011-03-23 15:35:25 PDT
Created attachment 521334 [details] [diff] [review]
Once more, with feeling
Comment 19 Nick Thomas [:nthomas] 2011-03-23 15:36:59 PDT
Comment on attachment 521334 [details] [diff] [review]
Once more, with feeling

Patch for another bug.
Comment 20 Chris AtLee [:catlee] 2011-03-23 15:38:13 PDT
Created attachment 521336 [details] [diff] [review]
Once more, with moar feeling
Comment 21 Chris AtLee [:catlee] 2011-03-23 15:40:59 PDT
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 2011-03-23 15:43:20 PDT
(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 2011-03-23 17:12:52 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.