Tree Branches for Mozilla 1.4
Friday May 23rd, 2003
A branch has been created for the forthcoming Mozilla 1.4 release. Checkins to this branch require approval from firstname.lastname@example.org. Meanwhile, the trunk has been reopened for 1.5 Alpha development. See tinderbox for the latest tree status.
#1 1.5 alpha or 1.4.0?
Friday May 23rd, 2003 6:15 PM
I thought the 1.5 line was Firebird.
Did you think the developers flip a swicth and suddenly the Mozilla trunk is Firebird/Thunderbird instead of the Mozilla Application Suite? Development doesn't happen that way. It will be a long, slow, painful process to switch the trunk code, make the necessary changes to Bugzilla, reorganize the directories, and clean up the crufty C++ code. I'm sticking with the 1.4 branch at least until 1.5 final is out to avoid the mess.
The 1.5alpha release will have the Firebird UI. However, that change won't happen instantly - in the short term, the 1.5alpha builds will have the Seamonkey UI, until the code is reorganised to have the Firebird UI.
I did a whole load of speculating about this subject in the forums - <http://www.mozillazine.or…ums/viewtopic.php?t=11737>
MLefevre, I don't think you are correct. My understanding is that current Firebird becomes Mozilla 1.5 Pre-alpha and the foundation for the next generation Mozilla Browser. The same way, current Thunderbird become Mozilla Mail 1.5 Pre-Alpha. Asa, can you clarify?
The changeover will not be immediate. Read the lengthy "to do" list in the Roadmap.
Well if you read the section A New Roadmap, Points 1 and 2 and Points 1 and 2 of the Summary Rationale, it can be extrapolated that Moz 1.5 Pre-ALPHA will use Firebird and Thunderbird as their base code for further development and refinement and not as suggested that Moz developers were going to grab the current Moz 1.4 and convert it slowly into the leaner spearate apps Moz 1.5. There is no need to reinvent the wheel as MLefevre is suggesting.
They won't be "grabbing" the 1.4 code - that code is there already. They need to "grab" the Firebird code and make the builds with that instead. The process of switching to the Firebird/Thunderbird code is the "reorganisation" I meant.
It doesn't make sense to have the old Mozilla code sitting around, with additional alternative Firebird/Thunderbird code for those builds, but that is the current structure. They need to drop the Seamonkey UI code and move the Firebird/Thunderbird code over, and then change the build processes to reflect that. That's not a slow process of wheel-reinvention or any significant code writing, but it's not an instant thing either - it'll take a day or two.
So until they make the switch, we'll have a few 1.5alpha nightly builds with the old UI. Obviously it makes sense to switch as soon as possible - until then, people won't be doing any work on the Seamonkey front-end which is about to get dropped, but changes can be made to the back-end code (which is most of it), as that is identical in the old and new apps.
Does that make any more sense?
First, Moz 1.4 is not going to be dropped, that is becoming the latest stable branch from where major distibuitors (Netscape, etc.) will release their production quality products. The stable 1.4 branch will become their basis for their .0x or even .x bug fixes later on. All the bugzilla bugs in the CURRENT 1.4 record stay in place because they still apply to the stable branch.
Second, as the tree opens for 1.5 alpha development, bug fixes from most Moz developers will probably deal with GRE (gecko/necko runtime environment .. see application architecture diagram <http://www.mozilla.org/roadmap.html> ) and other backend code that is relevant to Firebird. GRE is NOT the Mozilla Application Suite 1.4, but a component used by it and by others, including Firebird. If I am reading the useragent for Firebird nightlies correctly, they build their product based on the development Mozilla trunk GRE etc.
Third, Mozilla hardware resources are not unlimited, so Tinderbox <http://tinderbox.mozilla.…builds.cgi?tree=SeaMonkey> must be adjusted to that reality and reflect Mozilla 1.5 building and development process.
Fourth, bug management might be messy at first especially if people get confused on where to report bugs and enhacements that apply to either 1.4 stable branch or 1.5 (Firebird) development trunk. Up until now there was one Mozilla, now we have two Mozillas, 1.4x and earlier (the Suite) and Mozilla 1.5 and higher (Firebird/Thunderbird).
Fifth, since Firebird (Phoenix) started as a proof of concept that proved that Mozilla as a standalone application and with a modified/simplified menu structure and modified XUL toolkit could be made significantly faster than the Moz App. Suite, Firebird can still continue its semi independent development from Moz 1.5 (Moz Browser / Moz Mail) by a limited number of developers.
#14 Re: Too many assumptions
by JBassford <email@example.com>
Saturday May 24th, 2003 8:32 PM
> Firebird can still continue its semi independent development from Moz 1.5 (Moz Browser / Moz Mail) > by a limited number of developers.
I don't think so. The last thing any of the developers want is a forked version of Firebird - one as a standalone, another as teh version that's part of the new Mozilla suite. From what I understand, the version of Firebird that's standalone will be identical to what you'd get as part of the suite. (Except, perhaps, for links to other suite applications that wouldn't make sense in the standalone version.)
From the Roadmap:
"Whether we'll be able to switch to Phoenix by the Mozilla 1.5 final milestone remains to be seen."
Is that clear enough on how long it will take to convert from the Mozilla Application Suite to Firebird/Thunderbird? It's not a matter of days or even weeks, but months. Your assumption that 1.5 alpha will be Firebird is entirely incorrect. They explictly state that even 1.5 *final* may not be Firebird. More questions? Please re-read the Roadmap yet another time!
You want Mozilla 1.5a? Here ya go :) <http://ftp.mozilla.org/pu…ird/nightly/latest-trunk/> <http://ftp.mozilla.org/pu…nightly/2003-05-21-trunk/>
That's it :)
What will happen to all the RFE bugs that apply to the front end or call for additional user exposed functionality? For example, I have a bug somewhere asking for per-site permissions management. This bug was a specific response to the mess in the 'tools' menu of Seamonkey, but is no less valid for Firebird (being able to set per site permissions would still be a useful function, and the UI would still improve the current UI). However, from what I know of the bug filing policy for the 'new world', such a bug would be immediatley WONTFIXed, or INVALIDated. Is this in fact the policy? It would also be nice if there was a way of marking a bug as a possible extension (this would allow prospective developers to easilly search for things to implement and so on).
I sure hope they won't all be wontfixed. There are lots of good ideas in there. If necessary, just assign them all to a new product/component. Then let developers take them if they want to.
#12 0.97>1.4b w2k w/ fresh profile hard to install
Saturday May 24th, 2003 5:08 PM
1st attempt at installing in /Mozilla.org/1.4b (custom path)
replaced my 0.97 icons and maybe my software.. didn't pop up the "would you like to make mozilla the default browser?" just stalled with no mouse response. then w2k asks me whether I would like to end the task, and I do. (no difference using old or fresh profiles). 2nd try uninstall 1.4b and 0.97 installed all componets (accident) installed to COMPLETELY custom path. (C:/Program Files/Mozilla1.4b)
there was a long delay when it asked me about being my default browser (answer: no)
now it is working fresh profile.