Guest post by According to a post on the mozilla.dev.planning Google Group by Mozilla Senior Director of Engineering, Damon Sicore, the ship date for the stable version of Firefox 4, Tuesday 22 March, has been approved by Mozilla’s IT and Marketing teams. Sicore notes that, should the developers discover any last-second blocker bugs that would prevent the final release, a second release candidate would be issued “as soon as possible” and the ship date would be reset. So far, the first RC has “received a very warm welcome”, said Sicore.
How stable is this thing going to be, really? If it’s like Opera, you’re better off waiting until the .01 version comes out.
PS: Betting I get modded down for the above statement, but hey… facts are facts.
Edited 2011-03-17 23:42 UTC
It went through no less than 12 beta versions and a release candidate.
Why would you not ask the exact same question of the recent IE9 release by Microsoft … which went through an entirely similar lengthy period of beta testing in almost exactly the same timeframe.
If they quit adding new features at the last moment and actually treated the beta and release candidates like proper betas and release candidates they might not have to go through so many versions and actually be able to get something out on time.
I hope the more frequent release schedule they are going to will help things out because they seem to have a very hard time letting a feature thats taking longer than they expected slip to the next release rather than delay the whole thing.
Edited 2011-03-18 02:36 UTC
Firefox 4 is a huge improvement over Firefox 3.x
The new plan seems to be to have more releases of lesser scope more frequently.
Firefox 5, 6 and 7 are apparently the planned releases for the remainder of this year, but they will all involve far less additional features each time.
I would imagine that the aim is to prevent Google Chrome from once again opening up a lead over Firefox.
Edited 2011-03-18 02:59 UTC
Hmm. Why is it important that new Firefox versions arrive at a certain, pre-determined date? Do you need to somehow prepare yourself for that, do you expect some specific kind of trouble then, or what?
I mean, I personally don’t really give a sh*t as to whether or not they keep to some specific date as long as the release is full-featured, working, and sports all such features as one could expect from a proper modern browser and as a successor to FF3. I’ve never really believed in release dates and as such I’ve never given them any weight whatsoever, I just concentrate on other stuff and take it when it’s released.
I guess this too comes down to tastes then.
I believe the issue that the GP poster was referring to was more in the line of a release process, rather than wanting a release sooner just for the sake of having it sooner.
Throughout the betas the Firefox team seems to have been adding more features. Usually you’ll enter a feature-freeze period where you just concentrate on fixing all the bugs that your new features have introduced. If a feature isn’t ready by the freeze-date then you just let it slip to the next release. By constantly adding new features up until the release, you have a greater chance of not being able to catch all the significant bugs.
I agree that the faster/smaller release schedule should be a better approach.
What exactly are all these new features people are complaining came late?
The only thing i can think of is the new JS engine (B6) and enabling D2D acceleration by default (Beta 7?).
Without those two features, FF4 would be way behind the competition, so i definitely think the release should have been delayed until those features were done.
Just examine any set of release notes, http://www.mozilla.com/en-US/firefox/4.0b11/releasenotes/.
If those features you mention were deemed essential to the release, then I feel that they should have been included before the betas began.
Yeah, I have been. Let’s take a look at exactly what was changed in that b11 build.
That comes out to:
2 smallish UI changes, including 1 that was fixing something highly complained about (so you could call it a bugfix)
2 bug fixes
Adding the DNT header, a very small feature that didn’t affect the release at all. It was done, and any regressions would just result in it being dropped completely. Note that the browser itself does nothing except send the extra flag to servers when it requests anything – it’s virtually nothing to implement.
No big deal, there.
Ah, so your real argument is that they should have just renamed the releases. So that beta 6 and 7 would be alphas, and beta 8-12 would have been called beta 1-5. Ok, whatever. That’s just semantics, I don’t really care what they name them.
Edited 2011-03-19 07:42 UTC
It is “just semantics” in exactly the same way a finished product is different than a beta. The two words mean different things, abuse the terms and they lose their meaning.
The first beta was 9 months ago… the way things are progressing it will likely be almost a year between first-beta and release. It just seems like they tried to do too much, an admission of that is the proposed change in release schedules.
No, they just define the term differently than you do. Mozilla calls anything a “beta” when it is supposed to be fairly free of crashes, and semi-well supported. Or in other words, when the quality takes a step up from early alpha builds. They don’t define it by saying it’s feature-complete, like the term was traditionally used.
I understand that conservative types really get pissed off when people change the definition of words, but it’s not losing it’s meaning. Just being changed.
Yes, but the problem with your definition of “fairly free of crashes” is that a beta can transform to not-beta by the introduction of a new feature that introduces an unacceptable number of crashes.
But this isn’t a global change of definition, it’s in that more mucky ground where everyone has their own (admittedly so do I!). Of course I just like my definition better
.
For the record, I also think it’s a little crazy to have 12 betas. 12! Especially when they kept adding lots of new stuff through the first 7.
I just can’t bring myself to care very much, and i think the last 5 betas were relatively free of new features and provided enough time for it to bake.
I do think the plan was to originally add in some of those new features earlier, and they just kept slipping back because they weren’t stable enough to stick in the first few betas.
Edited 2011-03-20 08:28 UTC
Because I don’t give two shits about IE9.
From all the browsers Firefox Beta/RC releases are most used. 60,000+ people even get daily builds.
Most Firefox Beta’s have been pretty usable. The code which was used to build the RC will be used for the real release because in the weeks after the RC-release no big issues where found so far.
I would expect it to be pretty stable.
Also a in a few weeks after the real release there will be updates obviously. Like with 3.0, 3.5 and 3.6 there will probably be security and smaller stability updates.
Firefox 5 is expected to be released in 3 (!) months and 6 and 7 also this year.
Supposedly any feature which isn’t stable after a few months will be reverted last month before release (of 5, 6, 7).
I wish them luck
I had issues with the earlier betas, but I just tried latest RC yesterday and it seems plenty fast and stable now. Hardware acceleration most likely will cause an issue or two at the beginning, but I don’t think it’ll be anything major given how good the RC seems.
I can’t say anything about javascript speed or such as I don’t use any javascript-heavy sites, but general speed seems a tad higher than current generation and what little I did test I couldn’t crash the thing.
So far it seems I’ll be happily switching to Firefox4 once it’s out. And hopefully this provides atleast some insight for your question.
I’ve been using FF4 for a month. I haven’t had any issues. A lot of sites actually work better (blogspot in particular).
Uh, really ? I mean, I’m glad to hear that, because I’ve had to resort to Chrome editing my blogspot entries, FF3 was terribly slow and clumsy. so good news. The bad news is that the Linux builds doesn’t seem to have the option to enable that Ribbon-like button, just as on Windows builds, or have I got it somehow wrong ?
The next releases, adopting the Chrome’s numbering with major digit, should bring, as they say, response of less than 50 ms for each user action, which is my pain with FF – the UI was very slow, compared to the usual counterparts. So, I hope for the best in a few weeks.
Hide the menu bar.
I’ve been running FF4 nightlies for >6 months and have not seen a crash in the last 3, nor any other problem that wasn’t by design. Of course some oddities remain and extension support is spotty, but now that there’s a release date I expect most authors who haven’t updated yet to get busy.
I’m using Firefox 4 right now.
Out of Chrome and IE 9, FF4 is my favorite browser yet.
I’ve been running the firefox 4 beta and now RC for a few weeks and it runs well. Same as firefox 3, just faster.
They did move the buttons and the first thing I did was customize the toolbars and move the buttons to the same as firefox 3. That was it.
Atleast that is what I understand from this thread:
http://groups.google.com/group/mozilla.dev.planning/browse_thread/t…
I used the betas up to beta 11 without any problems at all, then updated to the release candidate to find that it does not cope with dark gtk themes very well – painting the tabs as white text on white backgrounds. Fortunately this can be overcome by using a dark firefox theme.
Of course, with a heterogeneous set of platforms, your mileage may vary.
http://arstechnica.com/open-source/news/2011/03/mozilla-outlines-16…
“Although Mozilla is still readying Firefox 4 for its official release, the organization is already laying out its plans for subsequent versions of the open source Web browser. In a roadmap published earlier this year, Mozilla revealed plans to issue three more major releases during 2011–bringing the browser’s version number up to seven.
As we discussed in our coverage of the roadmap, Mozilla’s plan is ambitious and will require a dramatic overhaul of the Firefox development process. Mozilla^aEUR”which has historically had lengthy development cycles and protracted beta testing^aEUR”will have to transition to a faster and less-conservative approach to release management. The organization has authored a document that describes how such a transition could potentially be achieved.”
They have been listing keychain, dictionary and services on their platform requirements since version 1
https://wiki.mozilla.org/Firefox/Namoroka#Firefox.next_Platform_Requ…