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.
More information about Mozilla 1.4.2 can be found in the Mozilla 1.4.2 Release Notes, with builds available from the mozilla1.4.2 directory on ftp.mozilla.org. This likely to be the last release from the 1.4 branch; 1.7 is expected to become the new stable baseline after the release of Mozilla 1.7 final in a few weeks.
#1 1.4.2 - thanx !!
Tuesday May 11th, 2004 9:37 AM
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 !
#2 Innovation has been slower than molasses (roadmap)
Tuesday May 11th, 2004 4:32 PM
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.
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:
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.
#3 Re: Innovation has been slower than molasses (road
Tuesday May 11th, 2004 6:05 PM
> 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.
#5 Re: Re: Innovation has been slower than molasses (
Tuesday May 11th, 2004 8:34 PM
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.
#6 Re: Re: Innovation has been slower than molasses (
Tuesday May 11th, 2004 9:31 PM
#19 Re: Re: Innovation has been slower than molasses (
Friday May 14th, 2004 10:12 PM
"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.
#20 Re: Re: Innovation has been slower than molasses
Saturday May 15th, 2004 4:44 PM
I don't think he meant that, and I don't think that is the case.
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".
#12 1.4.2 has "thousands of bug fixes" ?
Wednesday May 12th, 2004 12:39 PM
1.4.2 has "thousands of bug fixes" according to the release notes.
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.
#13 Next Killer feature
Thursday May 13th, 2004 3:28 AM
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
#14 Re: Next Killer feature - flash blocking
Thursday May 13th, 2004 7:26 AM
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"...)
Tuesday May 11th, 2004 6:20 PM
What do you think about the 6 month thing? Would it help?
#7 New features
Wednesday May 12th, 2004 1:54 AM
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.
#10 Re: New features
Wednesday May 12th, 2004 11:44 AM
If 1.4.2 is unsuitable, I'd say think about skipping 1.5 and going with 1.6 (or 1.7 when it comes out). The reason is bug fixes.
#15 Re: Re: New features
Thursday May 13th, 2004 9:54 AM
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 220.127.116.11, 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.
I just *might* take your advice into consideration.
#16 Re: Re: Re: New features
Thursday May 13th, 2004 11:11 AM
That's a good strategy.
I would only add that from 1.4.2 to 1.7, very little has been changed other than bug fixes and tweaks. 1.7 is supposed to have less bloat than prior versions, for example.
#18 Re: Re: Re: Re: New features
Friday May 14th, 2004 6:51 AM
I usually have the feeling that bigger versions have more bloat inside, such as IE 5.5 compared to IE5.01SP2.
#8 Mozilla 1.3.1 Still
Wednesday May 12th, 2004 4:06 AM
I'm still using Mozilla 1.3.1, and I won't change any time soon. Since it is the last Mozilla browser that could use IE Favorites directly.
#9 Re: Mozilla 1.3.1 Still
Wednesday May 12th, 2004 4:17 AM
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.
#11 Release Cycles - one for all?
Wednesday May 12th, 2004 11:59 AM
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.
#17 Re: Release Cycles - one for all?
Thursday May 13th, 2004 11:37 AM
This could be done if we had enough frozen apis that the apps only used frozen apis. Then the gecko development cycle could be decoupled from the app development cycle.
We may get there by 2.0 (are trying to, in fact), but it'll take a lot of work.
#21 Re: Release Cycles - one for all?
Monday May 17th, 2004 6:49 AM
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.