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.

What do you think about the 6 month thing? Would it help?

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'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.

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?