Slashdot Mirror
Mozilla 1.4 RC1
Mister.de writes "Mozilla 1.4 RC 1 is out. We've added lots of features and fixed lots of bugs since Mozilla 1.3. Help us shake it down in preparation for Mozilla 1.4 final. More information is available in the release notes. Mozilla is an open-source Web browser, designed for standards compliance, performance and portability."
Excellent. This was the only reason I kept a copy of explorer around. Now to see if it works. :)
The next release won't be 2.0. Although the front end is changing to the new toolkit, and the all-in-one suite is being abandoned, the code at the core will (the Gecko layout engine, necko networking library and so on) still be the same and, in particular will not represent a big break in backward compatibility from 1.0.
However, in the 1.5 and 1.6 cycles, it is anticipated that there will be some big backend changes (code simplifcation, rearchitecture work) that will break API compatibility with 1.0. There is also a move to distribute the core librarys seperatley in a form called the Gecko Runtime Environment, which will make it easier for other products to utilise part of Mozilla without needing to distribute the whole suite in their application. All of this means that 2.0 isn't a sutiable name for a few release cycles yet. In addition, it is quite possible that the version numbers of the front end and the back end will no longer be the same (for example the next release might be Firebird 0.7 with Mozilla 1.5)
I completely concur that using 1.4 as the latest 'stable' makes sense, until the 1.5/2.0 version becomes tried and accepted as stable.
Release version numbering should follow major changes in the base code. The specifics listed thus far in this discussion reflect that this will be the case with Mozilla in it's next release (*Disclaimer* - I didn't spend time researching them myself, so I'm basing this comment on earlier comments in this discussion and understanding of Mozilla's development in general).
A classic example is Redhat, of course. With versions 6 and 7, the *.0 release was widely considered stable and tested enough for the typical end-user, but not for 'enterprise level' deployment, esp. on the server side. I have read many comments (and agree) that most businesses waited for a version *.1, *.2, or *.3 before migrating, giving the time necessary to fix any unforseen issues that didn't appear in normal testing.
I concur that a move to a version number of 2.0 is warranted when the change is made to Firebird. The 'refined, heavily tested' version cannot be made available until after the initial release (into production environments - testing will NEVER be able to account for all possible situations).
Silly me, I'll just crawl back into the server rack now. Unlike the kernel, it *is* an end-user product. The Mozilla team can go "it's just for testing" all they want, but it's not the truth. It is being deployed on Linux machines as the end-user browser.
If you remember the Mozilla 1.0 Manifesto, you'll see that one of the most important point of that release is: Personally, I would consider the separate browser and mail spin-offs as a completely unforseen development since 1.0, and that this would have been an excellent policy if they had continued on a unified tree.
However, what they are doing is changing Mozilla drastically, both in terms of structure, as well as the changes that have been made to the browser and mail components, and this is not a natural successor to the 1.4 release, rather a separate branch since 1.0 (or whenever these spin-offs started, haven't kept track).
To me, that suggest that the browser should have version 2.0. It would far more accurately describe it to the end-users you claim do not exist. Nothing would be easier than to specifically state that the XUL 1.0 API has *not* changed, and that all things working in 1.0 will continue to work perfectly in 2.0. The people that need to know (developers and whatnot) would care enough to find out that "nothing" has changed, while the people actually using Mozilla will be made aware that there's been a huge change.
Kjella
Live today, because you never know what tomorrow brings
Please don't discourage him. The editors could learn something from him. I'm sick of articles of the sort: "Foobar gets AutoFrotzing" where Foobar is an obscure kernel module or some video game and frotzing is something you would only have heard of if you had been following that module or video game yourself.
What's so hard about defending the claim for standards-compliance? Mozila is, by a very long shot, the most standards-compliant browser in existence. Internet Explorer has not-too-bad CSS and DOM support, but can't claim to support either as well as Mozilla does. There's also all the standards that IE doesn't even try to do right -- MathML, which is hugely important for those of us who use it, PNG, which IE only sort-of supports, XHTML, and SVG, even though it's off by default. These and many other open standards are supported natively by Mozilla, something that no other browser can claim to do (not even Opera or Konqueror/Safari).
As for performance ... Mozilla is actually very fast, in some ways. The Gecko HTML engine is one of the fastest around, and handles super-complex CSS positioning with ease. (Yes, KHTML and Opera can be faster, but this is partly because they don't support many of the more complex aspects of CSS).
Also, although the Mozilla integrated suite takes forever to start up, Firebird/Phoenix is a good deal faster, and Gecko front-ends like Epiphany for GNOME and K-Meleon for Windows start up fast enough that if you blink, you'll miss it.
And finally: "fairly" portable? C'mon, there is no other browser that's available for as many systems as Mozilla is. Ever tried to use IE or Opera on BeOS, Irix, OS/2, or OpenVMS?
Living in Perth, Australia? Come to our Slashdot Meetup