Closed Bug 636190 Opened 9 years ago Closed 9 years ago
Change firefox version on mozilla-central to 4
(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?
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.
Ok, I think we want to do this but hold off on doing this until beltzner weighs in.
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.
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?
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.
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.
(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.
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
The point we branch is separate, but I'm sure we'd appreciate an indication of when that might happen.
Whiteboard: RelEng should inform metrics when this happens
Priority: -- → P3
Whiteboard: RelEng should inform metrics when this happens → [releases][inform metrics]
(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.
see-also: Bug 644011, we bumped the milestone tonight; still have to do the main Firefox version.
Attachment #521157 - Flags: review?(bhearsum) → review+
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.
Summary: Change firefox version on mozilla-central to 2.0pre → Change firefox version on mozilla-central to 4.2a1pre
bsmedberg points out we should keep 4.0 users on mozilla-central for now
Attachment #521163 - Flags: review?(bhearsum) → review+
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.
Attachment #521163 - Flags: review?(nrthomas) → review+
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 on attachment 521334 [details] [diff] [review] Once more, with feeling Patch for another bug.
Attachment #521336 - Flags: review?(nrthomas) → review+
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
Attachment #521336 - Flags: checked-in+
(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.
(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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.