Trunk Frozen for Mozilla 1.5 AlphaWednesday July 9th, 2003At midnight Pacific Daylight Time during the night between Tuesday and Wednesday, the main Mozilla development trunk froze in preparation for the release of Mozilla 1.5 Alpha. While the tree is frozen, all checkins to the trunk require approval from drivers@mozilla.org or they will not be allowed to land. The freeze is expected to last for a few days and the trunk will be reopened when Mozilla 1.5 Alpha is released. Note that 1.5a will be a Mozilla Application Suite release as Mozilla Firebird and Mozilla Thunderbird are not yet ready to become the default applications. See the Roadmap for more details about milestone schedules and future development plans. Which release will feature the new components? Also, architecturally speaking, will the distribution feature a single Gecko Runtime Environment on which the components draw their resources or will they all contain parts of the GRE as they are distributed now? Well the idea was that it might happen during the 1.5 cycle. however, given that it hasn't happened yet, that's not looking likely, so I guess it will be some time in 1.6. It seems drivers have decided to stick to the date schedule, rather than holding things up for the component switch around, so there's no definite plan for which release will have the switch - all depends how the work goes. As for the GRE, the idea is that they will all share a single GRE. That may or may not happen initially - again, depends how things go. Last thing I saw was that the split would be for 1.5b, but 1.5a would still be Seamonkey. I have no friggin clue why. Don't knwo exactly the criteria to establish the version number, but I think, based on previous experience with commercial products, that a major change like this (breaking the suite into single components), justify a new number. So they should be Mozilla Browser 2.0, Mozilla Mail 2.0, and so on. Besides, a number 2 reflects the maturity the Mozilla browser has already got. No, probably not. Mozilla.org is not worried with version numbers. Netscape and other commercial companies use version numbers to garner more attention...but Mozilla isn't exactly commercial is it? That's a debatable question. Since it is a competitive product and a market share owner and seeker (since nobody builds a project this big for self use), I use to think on Mozilla as a commercial product, although free. Recent discussion about Mozilla company-wide implementations in MozillaZine (http://www.mozillazine.org/talkback.html?article=3369) and Slashdot.com (http://ask.slashdot.org/askslashdot/03/07/03/0039200.shtml?tid=126&tid=154&tid=187&tid=95) seem to confirm this. My opinion and would gladly discuss on this. As for versioning. I've been looking for Mozilla versioning criteria, which should exist, with no luck. I agree that some version number changes reflect more a commercial interest than a true improvement (chose your favorite app as example) but in this case I think it would be easier to refer to the Mozilla Suite as 1.x and the new one as 2.x The Roadmap will (or used to) tell you that the version numbers count branches. That is the only versioning criteria. After 1.4 comes 1.5. If 1.5 has some major flaw that needs to be corrected, it will be 1.5.1, 1.5.2, and so on. Simple as that. the stuff about versioning that exists is in the roadmap - http://www.mozilla.org/roadmap.html - and from there the 1.0 manifesto is linked - http://www.mozilla.org/roadmap/mozilla-1.0.html , which includes this: "A set of promises to keep compatibility with various APIs, broadly construed (XUL 1.0 is an API), until a 2.0 or higher-numbered major release. All milestone releases and trunk development between 1.0 and 2.0 will preserve frozen interface compatibility. Mozilla 1.0 is a greenlight to hackers, corporations, and book authors to get busy building atop this stable base set of APIs." In terms of the APIs, the switch of the UI isn't a big thing. A Mozilla 1.6 with Firebird and Thunderbird will probably have more in common with Mozilla 1.4 than, say, Mozilla 1.4 has in common with Mozilla 1.0. If you want to debate the question, the place to do that is the netscape.public.mozilla.seamonkey newsgroup - there's been a couple of threads about this already. Currently, the Mozilla.org folks seem to think things are fine with version numbering aimed at geeks and others that embed the Mozilla code, rather than the wider market. That is, in fact, supposed to be the audience for Mozilla. The idea isn't that the world uses Mozilla binaries, but that other people take the Mozilla code and use it in their own products, which are distributed... My guess: releases 1.5, 1.6, 1.7, etc. will be used for the transition to Firebird/Thunderbird. When the Mozilla developers are satisfied with what they have, then they will release 2.0. IIRC, asa and other developers has said several times that the major version number will only change when the APIs for embedders changes significantly. Just like in other big projects such as Linux, glibc, gcc and Apache. The Appsuite -> Firebird change doesn't break any APIs. I don't think the APIs are all stable, anyway. If they were, we wouldn't need different builds of spellchecker.xpi for different releases of Mozilla, but we obviously do. They are not _all_ stable. The ones marked @frozen are stable. Going to 2.0 would mean possible deprecation of a bunch of these... As for spellchecker, it uses a bunch of things that are not only not frozen APIs, but are not even APIs (it links to exported symbols that are not defined in any IDL files anywhere). So it breaks whenever things change, naturally. Actually, if Mozilla was a conventional commercial product then Mozilla 1.4 would have been Mozilla 2.0. Mozilla 1.1, 1.2 and 1.3 would have been internal 'milestones' (can't think where I got that word from...) towards Mozilla 2.0. Mozilla 1.5 would then be the first milestone in the progress towards Mozilla 3.0 I wonder if Mozilla.org will have a Mozilla 1.10 (thats one-point-ten, not 1.1.0). If you remember back before Mozilla 1.0, when Netscape 6 was released Mozilla.org was hoping to have Mozilla 0.6, 0.7, 0.8 and 0.9 before Mozilla 1.0. In the end they had up to Mozilla 0.9.9, but not 0.10.0 or 0.9.10. Now I've written that I don't know why I really care :) So what happened to Firebird becoming mozilla/browser? Will it happen in 1.5 beta or 1.6 now? Asa or anyone else in the know around? Perhaps I'll step out on the limb here and say that I don't think anyone knows. The Mozilla Roadmap sets out a lot of lofty goals that are difficult to achieve in a short time. If anyone states a specific date or even milestone when the change will occur I think they are being delusional. It certainly doesn't appear that the switch is going to happen within the 1.5 development release, and I'd wager that even 1.6 is pushing it. Mozilla Firebird is nice in it's current state, but there's a lot that needs to be done to it before it's a great standalone browser. Mozilla Thunderbird hasn't even had it's first milestone release, and it's a decent wager that it isn't even close. There's an old saying "Don't jump the gun." Perhaps the best thing to have done when the new Mozilla roadmap was released would have been simple to state "We plan to swith to standalone apps, but the timeframe it will take to do this is hard to predict." Why the are they still working on the app suite? Why not put all resources into the stand alone products? :/ Who is working on the old app suite? Are you doing it? I'm not doing it. In fact, pretty much no one is working on the app suite, as far as I can tell. The few people that are, are doing so because they feel like it; there's no way to dictate to people how they will spend their volunteered time. Fixes to XPFE can also applied to Firebird/Thunderbird in some cases. This is what happened in the early days of Firebird (when it was called "Phoenix" - remember that?). To see whos working on it: http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/browser/resources/content/navigator.xul However, wait until the 'stable' branch is switched from 1.0 -> 1.4. People will still have to work with XPFE there. |