Mozilla 1.4.2 Released

Monday May 10th, 2004

Thanks to herman for informing us that Mozilla 1.4.2 came out a little over a week ago. This latest release from the 1.4 branch features only bug fixes (no new features) and will be mainly of interest to developers building products from the stable branch. Most end-users will want Mozilla 1.6 or the upcoming Mozilla 1.7.

thank you for updating 1.4.1 into 1.4.2 -- i used 1.4.1 for the longest time. it was stable and better than any other browser i had ever used; long after 1.5, 1.6 & even early 1.7's. glad to see the security updates applied, i still miss it (though i am happy with 1.7b & 1.7rc1. i hope anyone (netscape or other) that tries to use anything other than 1.7-final as a starting point uses this instead. thanx for finally releasing 1.4.2 !

I say that with hesitancy. I don't want to be harsh, but I think it has got to be said.

In the past year since 1.4 was released, what have we actually accomplished?

1.4.2 has "thousands of bug fixes" according to the release notes. It also has NTLM support in the platform that needed it most, Windows.

http://www.mozilla.org/releases/mozilla1.4.2/README.html#new

Above and beyond what 1.4.2 already has we have added very few new major features. We did extend NTLM to other platforms. The only other thing that really stands out, though, is the spell checker, but so far that is mail-only. Composer and Browser text boxes have no spell checker.

The "what's new" section of the release notes for 1.5, 1.6, and 1.7 RC1 are at:

http://www.mozilla.org/releases/mozilla1.5/README.html#new

http://www.mozilla.org/releases/mozilla1.6/README.html#new

http://www.mozilla.org/releases/mozilla1.7rc1/README.html#new

As you can see, the totality of our efforts in the past year have been NTLM, spell checker, a few tweaks, and a lot of bug fixes. The result in 1.7 will indeed be a better product than 1.4.2. But it won't tremendously outshine it. Some people will stick with 1.4.2. Who could blame them?

Meanwhile Firefox has not advanced much feature-wise, either. Of course, there is a very good reason for that. We are getting ready for its 1.0 release.

My concern is the pace of the development of the suite.

Who or what is to blame for the slowness? I do not blame the developers. They are doing a great job. I don't blame the drivers. They're doing a great job, too. I don't blame the AOL-related organizational changes at Mozilla.

I put the blame on our overly aggressive release cycle. Putting out a new major release of the Mozilla suite every 3 months is the problem. This causes the alpha series to be open for checkins for only a short amount of time. In fact, while the next alpha branch is open for checkins, most developers are focused on finishing up work for the next major release, and are not focused on getting new stuff ready for the new alpha. Then the new major release comes out, and a few days later (it seems like) the new alpha branch closes for checkins! Our new features ideally should be checked in during the alpha cycle, not after. The current schedule makes this difficult.

There are major new features that the suite needs. Everything from a context menu for bookmarks to autosave of open web sites (for crash recovery purposes) and so on down the line. In particular, the Mail app needs a lot of new features to compete with Outlook, Eudora, and so on.

We can look back at the past year and be proud of all of the bug fixes, the minor new features, and the two new major features. But the coming year is going to be very hard.

Win XP service pack 2 will include a new version of IE. This will probably fix bugs, but most importantly it will contain a popup blocker. Consequently, our deadliest killer feature will no longer be our best selling point against our biggest competitor. Our next best killer feature is tabbed browsing. Unfortunately, many users have very simple browsing habits, and they will never need or want tabs.

We have the momentum. Mozilla and Firefox will continue to get new users, but if we don't do something to encourage more feature development the pace of new users will fall off. Dramatically.

We should increase the length of the release cycle to 6 months. Version 1.8 final should be released not sooner than November. Until then, we can just do minor revisions of 1.7 (1.7.1, 1.7.2) if that becomes necessary. This period of 6 months will allow developers to spend enough time on new features so that they will be ready for check-in for the next revision. A longer release cycle gives developers more time to code the big new stuff. Then, 1.9 can be scheduled for May 2005.

The other benefit of this is that it will help shift the public's attention to Firefox. The suite should stilll be developed. The Mozilla suite should be considered our "business user product" and testing platform.

Firefox should be what it is: the awesome looking flagship app that appeals to everyone across the board, bar none. I would include everyone from teenagers to college students to technophiles to suburban parents to older technophobic gentlemen. Firefox should continue to be based on the tried and true technologies of the suite + Firefox's own innovations.

As for the pace of Firefox's release cycle, we should keep it as it is: quick.

Then, every six months, Firefox can profit from the bumper crop of new features that we will hopefully have developed and tested on the suite.

> My concern is the pace of the development of the suite.
> Who or what is to blame for the slowness?

How about the fact that the suite is on a maintenance footing? That is to say, it is in feature freeze, for all intents and purposes. The only way new features are ending up in the suite right now is if they're actually features of Gecko, not features of the browser UI. And most Gecko work has been on basic arch, not features (CSS quotes, NTLM, etc being some notable exceptions).

> The Mozilla suite should be considered our "business user product" and testing platform.

The business users are the ones who are all for no new features; they just want security and crash fixes and preferably no changes in the UI, or so the story goes.

> Firefox should be what it is: the awesome looking flagship app that appeals to everyone across the
> board, bar none.

You mean "bar business users." ;) Cheerleading is nice, self-contradiction is silly.

> Then, every six months, Firefox can profit from the bumper crop of new features that we will hopefully
> have developed and tested on the suite.

Most of the things you have listed as desired features for the suite would need to be done totally separately for Firefox, so I'm not sure how that would work.

Its good that more focus has been on stability and efficiency lately. Mozilla is crashing a lot less which is important. Some new features especially for Firefox and Thunderbird are a good goal. The App Suite really just needs to focus mainly on reliability and trying to speed it up to Firebird's speed if possible.

One new feature that would be the same for both the suite and Firefox (I think) is finishing BlackConnect and Jrex. These are two components that when combined with Java and Gecko's HTML/CSS/Javascript/XUL would make a formidable platform that could challenge Avalon/XAML.

"How about the fact that the suite is on a maintenance footing? That is to say, it is in feature freeze, for all intents and purposes. The only way new features are ending up in the suite right now is if they're actually features of Gecko, not features of the browser UI."

Are you saying that nobody is allowed to update the browser UI?

Mozilla suite users, including me, are so scr*w*d...

P.s. a new confirmation dialog for 'Close Other Tabs' was added only recently so that's at least one new feature.

People are allowed to do things with the browser UI. However, the mozilla.org employees aren't working on it, so it's down to contributions from outside individuals. Therefore, the speed things moving is indeed "slower than molasses".

Compared to which browser? Mozilla 0.9.2? Mozilla 1.4?
Mozilla 1.4.1 had a lot of bugfixes compared to 1.4,
1.4.2 doesnīt have thousands of bugfixes, that would have required more than 10 checkins per day, and there have been weeks without checkin on the 1.4 branch. Most of the checkins were for os/2, I donīt think there is more than a double digit number of windows checkins.

What you say is quite true, in my opinion.
The only thing that I can think of that would server as the next "killer feature" is flash blocking. I don't think they will implement it though, because that would make some comercial interests angry (yes, I know about Adblock, but there is a big difference between an add-in and a feature being installed by default).
Besides that, they could try to improve existing features, such as download manager and form manager

there already is an extension "Flash-click-to-play" (as well as the prefbar "kill-flash"). both are quite useful, but still just extensions, not automatically included. would be nice if they could be added by default, (even if the initial default setting was "off"...)

Well, I think that new and noticeable features are indeed slow to come. While many of the feats are under-the-hood-based, then Mozilla 1.0, 1.2, 1.3 and 1.4 all came with something new...

For example, Mozilla 1.0 (the browser component) has tabbed browsing, image and cookie blocking, 1.2 is an improvement of all that, 1.3 began having Bayesian spam blocking and contained a server-specific pop-up blocker, but often crashed on one instance where I used forms (1.3.1), so I had to have 1.4.1.

I am very happy about 1.4.2's release, because it's mainly a security and stability release. Also 1.1 and 1.3.x seem to follow the pattern of developer-related test releases, as Linux [kernel] 2.1, 2.3 and 2.5 releases are. Seeing this deviation with 1.7 as the main stable release still seems very odd.

As for Firefox, then I continue seeing it as something that also gets to fit in older computers, as K-Meleon is still somewhat immature.

I also migrated e-mail from Outlook Express 6 to Mozilla Mail (1.4.1), but if Mozilla Mail keeps crashing after 1.4.2, then I would feel forced to upgrade to 1.5.x until mail handling stays stable.

I feel very conservative about upgrades and skipping in-between versions. 1.5.x should be better anyway than 1.4.2, if I am not satisfied with it (although I contend that 1.5.x is an earlier release anyway than 1.4.2, my satisfaction of any software depends on stability). My reasoning is that once there's a new computer, the newest software with the newest major version for it suits well and from then on I would only make minor updates. So that software with more priority would have breathing space in the future.

For example, I use a couple old and slow computers and one of them has Netscape 4.08 and I won't upgrade to more than that in Netscape 4.x terms. AIM is too a 1.6N version that came bundled with Netscape 4.08. IE also remains a 5.01SP2 version with updates. Acrobat Reader 3.02, QuickTime Player 2.1.2.59, Flash 6 for IE to sometimes view startrek.com (I blocked download.macromedia.com in IE to avoid drive-by installation of Flash Player 7) and so on and so forth. Probably the only new titles are Firefox 0.8 and msn messenger 5, which I won't upgrade. For these two titles I've kept everything else the same, save for updates for Windows and IE.

It's up to you, but you should be aware that 1.3.1 has some significant security flaws - everything from number 57 upwards on http://www.mozilla.org/projects/security/known-vulnerabilities.html I don't know if any of them are actually being exploited in practice, but they're there.

Look at Debian. IMHO their release cycles are awkward. Why does each and every package of the whole distribution need to share its' release cycle with every other package? Why don't they just set the stability rating for each package individually?

I think the Mozilla suite has the same problem. It is just not modular enough. My suggestion is to continue the Mozilla suite in an extremely modular fashion.

Release cycles could and should be set separately for each module. It is nonsense to delay simple add-ons because more complex ones need more evaluation or testing. It is not useful to delay mailclient updates or unimportant changes in the bookmark updates notification algorithms if the GECKO engine is under heavy development and so on.

Another benefit would be that as modules, the program features could be more easily used within other applications since it would require some sort of API specification.

And, possibly, one could install older versions of security critical modules (eg. Javascript implementation?) together with newer versions of the mailclient?

Debian's release cycle is good. Just as Windows' is good. Who wants to be constantly upgrading packages? I don't, and this is something that really irritates me with a lot of open source products. In a business environment it is even more critical as a few minutes here and there soon add up. I want a good stable product that doesn't need any attention for several years. Sure, I will apply security patches as needed, but in the case of Debian, the number is reduced due to their release cycle and the extra testing that naturally occurs in that time. Obviously Windows is a different story on that, and Windows XP SP2 is a step back to the bad days of NT4 when MSFT changed functionality in a SP... it makes it a new product and should be treated as such. This is why Debian, Windows, etc work. I use Mozilla 1.4 as my mail and news client, and am happy to do so until Thunderbird reaches a long term stable branch. I used Netscape 4.x right up until shortly after Mozilla 1.4 was released as data reliability is important to me.