AOL to Release New Netscape Update in Early SummerTuesday March 30th, 2004The Inquirer is reporting that America Online is to release a new version of the Netscape browser. The upgrade will be a "'point' release based on the latest Mozilla code" and "will be made available in the very early summer timeframe." Speculation that an update was in the works began last week, when the San Francisco Bay Area's Mercury News paraphrased an AOL spokeswoman as saying that "there will be future versions of Netscape that are essentially repackaged upgrades of Mozilla." The confirmation that a new Netscape release is on the way does not indicate that AOL is planning to provide any further development or financial support to the Mozilla project. Indeed, no AOL employees are paid to work on Mozilla and we can expect this latest version to be even more similar to Mozilla than previous releases. The more intriguing question is what made AOL change its mind about shelving the veteran browser. I think this can only be good news for Mozilla. People who know about Mozilla will continue using it (increasing firefox rather than the suite), where as people who don't know about Mozilla will see that Netscape is still being developed, so will continue using it. I also think is has been helpful for Mozilla that AOL initially said that they wouldn't be producing any more versions of Netscape - it has forced the organisation to that the new, consumer focused approach rather than relying on Netscape for that. From AOL's point of view, it also seems to make sense. From the sound of it they are just going to be slapping a few Netscape icons on it, so it won't cost them much more than the download bandwidth fees, but it will keep the Netscape brand alive and promote their portal. If they want to add more adverts to it like before, then that could also earn them money. The previous Netscape releases were based on the stable branches on Mozilla, 1.0 then 1.4. Beings this release is slated to be available this summer, one must assume it will be based on the 1.7 branch. Does this mean that 1.7 will replace 1.4 as the current stable branch? I thought that making 1.7 the current stable branch made sense because Firefox 1.0 was going to be based on the 1.7 branch. But this news makes the case even stronger for 1.7 to replace 1.4. In my opinion, suddenly making something a stable branch post-facto is an incredibly bad idea. Stable means API stability, and that means not having half-baked API changes straddling the branch, as much as possible... Which requires some advance warning. I think this last minute making this a stable branch idea may be due to that lack of communication between the firefox crew and the rest of the crew. They decided to make Firefox based on 1.7 and the other guys are like whoah we better stablize this branch then. But that brings up the netscape question. When did the mozilla foundation find out that there was going to ba another Netscape. Or is AOL jumping on this branch and making another Netscape because it will be a stable branch. So which came first the chicken or the egg? Which came first firefox's need for a stable branch or netscape's need for a stable branch. I'd suspect firefox's need came first even though it came later than it should have. And AOL was just waiting for the next stable branch to jump on. > and the other guys are like whoah we better stablize this branch then. More like "whoa, that would have been nice to know at the beginning of the 1.7 cycle, but it's too late to do anything about it now", actually. This whole situation makes me rather sick to the stomach, frankly. We said we'd maintain 1.4 for about a year. Drivers have been discussing whether to use 1.7 or 1.8 as the next stable branch for several months now. Firefox, Thunderbird, Seamonkey, other vendor products are all lined up to do releases from the 1.7 branch. It's been about a year since the last "stable, long-lived branch" and so I've floated a proposal to drivers suggesting we make 1.7 the 1.4 replacement. I haven't heard any objections from drivers yet so I expect to publish the updates to the milestone schedule soon. In the mean time, maybe some Milanta would help. I think the problem is not about having been discussing the plan from a long time. The problem is letting enough time between the decision and the act of freezing. If it was known that there was to be a long lived branch on 1.7 or 1.8, decisions should have been made to prioritize issues related to API stabilitization so that these issues would have been resolved before the actual long lived branch. Instead it looks like the bread is half baked. So from an engineering perpective, I think this is a mistake. Furthermore it seems presomptuous in one way to only consider this or that project. There are many people working on extensions and in these develpers may lay the future of the project. Some of them will be future developers, many of them are making great efforts to advocate the mozilla line of tools. Not considering non-mozilla project as well, like Galeon and such is really a bad idea. If I was a non-paid developer working on one of these projects, I would be so pissed off that I would consider trying to embed IE engine on Linux instead. At least API is stable there. I am not a mozilla developer, and as such I have nothing to say. But I am an early adopter, bug reporter and I've converted many people to the tools of the mozilla suite. Asa, I am calling to your sense of leadership there. I may be wrong, but I think this is a mistake. This decision makes me sad, and I would be happy if it could be reconsidered. Maybe the idea of making a short 1.8 (e.g. 7 weeks), used to implement the changes on top of the stabilizations issues fixed in 1.7 could make everybody happy? But on Jan 28th it was announced that Camino would release .8 off the 1.7 branch and soon after that Fire(bird)fox development followed that some line... it really isn't some sudden thing... 1.7 reached alpha state about a week later. Projects like Camino and Firefox need to have *current* branches to release off of... and both projects could see a potential release date around April. I personally thing to many people are stuck on SeaMonkey time... Announced where? I can't find anything on the obvious newsgroups and there doesn't seem to be any mention of the plans in the staff meeting minutes. I can't see any mention of it on the roadmap (in fact, the roadmap still points to 1.4 as 'replaceing 1.0 as the longlived branch). There was some discussion in November about when the next stable branch would be, but clearly no one knew at the time. Moreover, the 28th of January was after 1.6 branched. However these plans were 'announced' it was clearly ineffecetive in informing the wider developer community, as evidenced by the fact that Boris didn't know. Maybe I haven't been paying attention, but until this thread, I had no idea that 1.7 was going to be the next long-lived branch. I expect that external embeddors are going to be pretty surprised too. > But on Jan 28th it was announced that Camino would release .8 off the 1.7 branch A blog comment doth not an announcement makes. Most people have better things to do than read random blogs. A post to the project mailing list / newsgroup / forum also doth not an announcement make, in this case, since the idea is to clue in people who are NOT directly involved with the project (and hence have better things to do than read said list/newsgroup/forum). "Stable means API stability." Stable means a branch from which vendors (including mozilla.org) can plan to release products and possible updates to those products. We said we'd try to maintain 1.4 as that branch for a year or so. We're coming up fast on a year and frankly, 1.4 is feeling pretty sad compared to the current state of things. We don't promise API stability on the trunk after the stable branch just like we didn't on the trunk after the 1.0 branch or the 1.4 branch so the trunk is free to evolve as it has been. If APIs need to be cleaned up for the 1.7 branch, under my proposal, we've got about a month and a half to get that done. Asa, major api changes are NOT something that should be happening at this stage for 1.7. We're talking changes that would have significant regression risk and all. For better of for worse, 1.7 will have the apis we have now; if it's made the new stable branch we're stuck with some major api issues for another year of vendor releases. Oh, well. It's not like any of us care about the quality of the product we produce, right? A simple heads-up during alpha would have allowed some prioritizing of api work to happen in the 1.7 milestone. That would have been consistent with how past stable branches have been handled, as I recall. Perhaps I was stupid to assume that this one would have been handled the same way and should have kept track of the discussion drivers were having on "whether to use 1.7 or 1.8 as the next stable branch". That would have given me plenty of notice, right? "It's not like any of us care about the quality of the product we produce, right?" I guess we could follow your suggestion and treat 1.7 as just another Mozilla milestone with little concern towards stabilizing it. Let's just branch and ship it as it is today. Just because Firefox 1.0, Thunderbird, SeaMonkey, and other major vendor releases intend to ship products from the 1.7 branch doesn't mean we have to care about making it stable. Just because millions of end users will be downloading releases from the 1.7 branch (probably an order of magnitude more users than will be downloading the 1.8 SeaMonkey release) doesn't mean we should put any more effort into ensuring that those products don't crash and burn. I suppose you're correct that it's much more important to get our APIs just right for a 1.8 branch that _won't_ be used by anyone beyond a single SeaMonkey release than to drive some stability into the 1.7 branch that _will_ be the basis for major releases. Giving millions of users a stable product shouldn't be allowed to get in our way. What was I thinking. Asa, I think you're being needlessly sarcastic towards bzbarsky, and accusing him of things he didn't say (e.g., "treat 1.7 as just another Mozilla milestone", etc.). What he did say was: major api changes are NOT something that should be happening at this stage / we're [now] stuck with some major api issues for another year / heads-up during alpha would have been better. He was not saying that we should freeze API's for 1.8 AND keep 1.7 as the stable release. He was saying that if 1.7 is to be the stable release, then the API's should HAVE BEEN frozen, and the decision to use 1.7 annonced earlier. Maybe you just misunderstood him. Or maybe I'm misunderstanding you both. :-\ I have no problem with stabilizing 1.7 crash-wise and such. We should do that. I have problems with declaring it a long-lived API-stable branch. I have MAJOR problems with the fact that we are letting vendors force our hand as to what will be a long-lived stable branch and what won't be. That should be a decision mozilla.org makes. Vendors can have input into it, sure. But then they should provide that input at an early enough date that mozilla.org can adjust accordingly. Frankly, in my opinion the right response to Firebird's last-minute announcement should have been, "No, wait until 1.8 when we will have had some advance warning and can stabilize the branch properly." As it is, tons of extensions will break from 1.7 to 1.8 or 1.9 (and from FB 1.0 to whatever they call the next version, but FB made that bed themselves) as APIs change and it will be a major pain for users. "I have no problem with stabilizing 1.7 crash-wise and such. We should do that. I have problems with declaring it a long-lived API-stable branch. I have MAJOR problems with the fact that we are letting vendors force our hand as to what will be a long-lived stable branch and what won't be. That should be a decision mozilla.org makes. Vendors can have input into it, sure. But then they should provide that input at an early enough date that mozilla.org can adjust accordingly." And when a significant number of the vendors/projects (for example, Firefox, Thunderbird, Camino, and others) say "we're shipping a 1.7 based product that we intend to maintain for some time" then mozilla.org should just say "too bad, our efforts are on the 1.8 branch that no one intends to use"? That doesn't seem terribly productive to me. We can make 1.8 as maintainable as you like but if the products that are going out to millions of users are shipping (and shipping updates/point releases) off of 1.7, then it just doesn't matter how maintainable or api complete 1.8 is. What would you propose we do? We could cancel the 1.7 release and branch so they _couldn't_ use it (though I suspect we'd just have a Firebird 1.0/Thunderbird/Camino branch in its place). Maybe we could change our license so that people were disallowed from shipping end-user products from code branches that the developer community didn't like? In a perfect world we'd have known that these projects were going to end up on the 1.7 branch with advanced notice of several months or more. We'd have announced this far and wide and developers would have had more opportunity for getting APIs finished out and major features or bugs fixed. But we're not in a perfect world. Things didn't start to line up until right around the time of developer day. Projects (Firefox, Thunderbird, SeaMonkey, Camino, others) converged on 1.7 late in the game. Part of the reason they converged on 1.7 is because 1.4 is so outdated (having branched about a year ago). It's considerably slower, it's missing some key new features, and it's not going to be maintained. Those projects all wanted something newer than 1.4, they're not waiting another 3 or 4 months for 1.8, and they need (and will contribute to) a stable branch from which they can ship and ship updates/point releases. We can work with that or we can not work with that. Well maybe if the foundtation had had a reasonable long term plan, you could have pointed embedders toward the branch that you had *already* decided to make stable. If these discussions had happened around November (when the issue was brought up in netscape.public.mozilla.seamonkey), you could have polled Firefox and Camino people for input and made the decision before 1.6 branched. I think that the summer target for Firefox 1.0 has been around for long enough that they could have requested 1.7 as a stable branch. Instead, it looks like you've gone "plan? what plan? Oh fuck, we need a plan. Uh, well we don't have a plan but, uh, these people do, so, uh, we'll do whatever they say". We did poll those people in November, and again in December and again in January, and again in February, and again in March. In November, it looked like 1.7 or 1.8. In January it looked like 1.7 or 1.8. In February, it started to look more like 1.7, but 1.8 was still a possibility. In March, 1.7 won out. We've been working since 1.6 was wrapped up to 1.7 more "stable" than 1.6 (in terms of crashers). There's been a big push to acquire a license and get talkback servers all set up and to get the talkback clients shipping in milestone and hopefully nightly builds too so that we could recover some stability that Camino, Thunderbird, Firefox, and even SeaMonkey were all begging for. We've been landing the remaining features that these apps needed to ship and cleaning up after those features. Around developer day, they basically all started to converge on 1.7 rather than 1.8. Now, we could say "screw you, 1.7 is gonna crash all over the place and we don't care about your releases" but we decided to say "well, then let's all start working to get 1.7 to be the most stable milestone we've had and that's what's been happening since. Yeah, but March is too late to decide that a milestone that is supposed to ship in April and has already been through much of its development cycle is supposed to be a stable for embeddors release. Hopefully it's not too late to decide that it's going to be a stable as in doesn't-crash release. Since, I'm told (somewhere on this thread), that both Firefox and Camino had decided to go with a 1.7 based release in January, the decision could have been made with their input then. In any case the drivers should have decided earlier and been prepared to tell people what plans they had made, rather than just waiting on everyone else to make plans. > we're shipping a 1.7 based product that we intend to maintain for some time" then mozilla.org should > say "too bad, our efforts are on the 1.8 branch that no one intends to use"? Perhaps the appropriate thing to say is "isn't it a little too late to decide this now?" Perhaps the appropriate thing is to push back 1.7 accordingly so that we can give them something worth shipping. As it is, we're screwing over all the other embeddors because of what Firefox/Camino/Thunderbird want. Would we have done the same if the branch was wanted by Epiphany and Galeon instead of Firefox/Thunderbird/Camino? If not, why not? Is there a significant discrepancy? Or is the fact that those projects are more closely tied to Mozilla.org coloring our judgement? (I suspect the latter.) > What would you propose we do? At this point? How about clearly communicating to the projects forcing your hand on the issue that what they are doing is NOT acceptable? That some little tiny bit of prior warning is absolutely needed if they want a decent branch to work off? I'm not sure actually pushing back 1.7 at this late stage is doable; it would put it on a 1.8-like schedule, what with the risky changes that I feel should happen... So at this stage your best option is probably to curse that you're saddled collaborating with people who don't seem to understand the concept and feel that the world should revolve around them. > We can work with that or we can not work with that. Quite frankly, if people are clearly not interested in working with me then I'm not that interested in working with them. Which means that I intend to make no special efforts (nor can I, given other constraints, even if I wanted to) to deal with issues on the 1.7 branch. But that's my personal response to the situation. You're free to do whatever you will, of course (though my suggestion is that you go and give some people a nice stern talking-to about communication). "As it is, we're screwing over all the other embeddors because of what Firefox/Camino/Thunderbird want. Would we have done the same if the branch was wanted by Epiphany and Galeon instead of Firefox/Thunderbird/Camino? If not, why not? Is there a significant discrepancy? Or is the fact that those projects are more closely tied to Mozilla.org coloring our judgement? (I suspect the latter.)" I think it's very likely that we'd give similar consideration to anyone that's capable of giving us the distribution that this lineup of 1.7 based products will. Firefox is out-downloading SeaMonkey nearly 2 to 1 for the last release and I don't think that Epiphany or Galeon are going to come close to the numbers that Firefox 1.0 and Seamonkey 1.7 get? What about k-meleon or Forumzilla or some random mozdev project? Do I give them all equal consideration? Not a chance. They're not equals. And yes, that Firefox, Thunderbird, and Camino (and SeaMonkey) projects are "more closely tied to mozilla.org", (more than that, they _are_ mozilla.org projects) probably does color my judgement. I've always had a softspot for the products we actually ship with our name on them and for some silly reason I think it's important that we ship good SeaMonkey, Firefox, Thunderbird, and Camino releases explicitely because we put our name on them. I put those prouducts above all the others in importance specifically because they have our name on them. I'm not speaking for the rest of drivers (many of whom represent other products entirely) but I don't see my bias for mozilla.org branded products going away any time soon. I'm not the least bit ashamed of that. > I don't think that Epiphany or Galeon are going to come close to the numbers that Firefox 1.0 and > Seamonkey 1.7 get? That's what I was asking about. Do you have any numbers to back that up? Or are we just assuming that since we don't have anyone downloading those off our servers they must not be used much? I'm as keen as you on having Mozilla.org projects be of high quality. But if these are Mozilla.org projects, shouldn't they make some token attempt to keep Mozilla.org drivers and the Mozilla.org community informed of decisions that will impact them? See what I said about trying to work with people who obviously don't want to work with you. "I think it's very likely that we'd give similar consideration to anyone that's capable of giving us the distribution that this lineup of 1.7 based products will. Firefox is out-downloading SeaMonkey nearly 2 to 1 for the last release and I don't think that Epiphany or Galeon are going to come close to the numbers that Firefox 1.0 and Seamonkey 1.7 get?" Seing that Epiphany is the main browser in the Sun Java Desktop which are aiming for some 200 million installs in china, and being sold at walmart I think they might outnumber Firefor/Thunderburd/Camino. I must say I have a softspot for any product shipping with gecko as a major component, from K-meleon and Epiphany to Crockzilla and Nvu. I agree there's nothing wrong with having a softspot for a project, but I hope that the drivers or staffs pet projects doesn't affect our release schedule. You obviously are missing the entire point. Yes, FX/TB/Camino are important. And the fact that they are going to be based on 1.7 is very critical and mozilla.org has to react and make 1.7 acceptable for these releases. But that is entirely different to calling it the next "long-lived" stable branch. I agree, Mozilla.org needs to give priority to it's own products, no one is dissagreeing with you. The problem is the "screw over" that many embedors will feel when you offer them a "sub-par quality stable branch" than what they would expect from a mozilla.org product. But reading you posts above, you obviously don't care about the quality of gecko/Seamonkey/ and embedors products. This has left me with aa very bitter taste. And as Peter pointed out, the major issue I have is the fact that developers are kept completely out of the loop on decisions like that. Sorry if that was not clear from my previous post, but if drivers were seriously considering this possibility like you said then they should have SAID SO. Publically and clearly. We have newsgroups for things like this. In addition to Mozilla developers, I'm sure there are also embeddors who would have loved to have some inkling that a new API-stable branch was in the offing, since that would have prompted them to push for bug fixes they want in products they plan to ship in the next year. So to summarize, I think that this decision was made for all the wrong reasons and more importantly in all the wrong ways. It pretty much epitomizes the chronic communication failures Mozilla.org has at their "finest." What are you talking about? No one has suggested that there's any problem with trying to fix up 1.7 to be stable in the sense of 'doesn't crash', given that there are several mozilla.org products releasing from that branch (although I doubt very much that Fiirefox 1.0 will have a 'pure' 1.7 at it's core; I thoroughly expect that fixes that go into 1.8 will be backported to the firefox 1.0 branch, given that it will be 2 months behind the trunk by the time it releases) that's pretty obviously a good idea. The problem is that mozilla.org stable releases are the preferred basis on which external embeddors are expected to build. Given that there are no security fixes for anything other than stable branches, embeddors either have to remain on stable branches or waste a lot of time keeping their product in sync with the trunk (difficult because $foo_random_embeddor doesn't get the luxury of turning the tinderboxes red everytime a checkin breaks their product). These are the people who are going to have to suffer for a year messing about with half-finished API changes. These are the people who will be put off embedding gecko because the API is inconsistent. If drivers have been discussion "for months" whether to make 1.7 or 1.8 the new stable branch, they should have made a decision and announced that decision before 1.7a opened for checkins so people could make sure it was worthy of being a stable release during the entire cycle. As far as I can tell, that didn't happen. Flaming people because they feel there has been a breakdown of communication is hardly likely to improve the situation. Finally, since you seemed to be on a roll of misunderstanding me, I would like to clarify my comments on caring about quality of the software we produce. I feel that the way this situation was handled by drivers will significantly reduce the quality of all Mozilla-based software that will ship over the course of the next year off the API-stable branch (assuming that's the 1.7 branch). And I intensely dislike being associated with shoddy work. Which is something that I've been forced into in this situation. That's the part that makes me sick to the stomach, as I said above. I rather enjoy working on this project, but if that results in situations like this one I may have to stop doing so. Memories of pdt abound and are very unpleasant. Asa stated that CrashWeek was done "in preparation for making the 1.7 branch the next "long-lived" stable branch" (see his blog or the full article for the CrashWeek article here)--so I'd say that they, or at least he, are/is planning on making it the next stable branch, replacing 1.4. This would good--not only for Netscape but also for Firefox 1.0. (Although if they do plan on stabilzing this branch, I'd think they'd better announce it more.) Switch to Firefox already!!! I have to concur :) > User: "Your website doesn't work in FireFox" > Webmaster: "FireWHAT???!" > User: "Er, um, Netscape 7.2. It just got released this year." > Webmaster: "Oh, really? I'll see what I can do." Note, Netscape problems do not evoke nearly a panic as IE problems do, but at least there is some recognition. And, conveniently, if it works with Netscape 7.x, it will work with FireFox :) I don't agree. i think mozilla passed the "what's mozilla?!" stage about a year ago, and if that webmaster doesn't know firefox, you can safely say "Mozilla" and in most cases, the answer will be "oh that..." IMHO: Developers must not shut out future versions of browsers and if they feel that a certain version of a browser does might not work well or so... There are developers that develop for future browsers and make everything platform-independent. Then there are developers that like to develop for specific browser versions and most caveats are there. I'm one of those sometimes and I develop my stuff distincting Internet Explorer /disregarding all of its subversions, Netscape 4.00-4.05 /less priority, 4.06-4.08 /more priority, 4.5x-4.8 /a little less priority, Mozilla 1.0.x /less priority now, 1.1 (less priority, was the last one to support coloured checkboxen and radio buttons), 1.2.x (a little less priority, was the first one after 1.1 not to support coloured checkboxes and radio buttons), 1.3.x /began having slight rendering differences with forms compared to previous releases, 1.4.x /more priority, Mozilla Firefox /any version, K-Meleon /any version. Interestingly, developers that like to distinct between versions of Netscape 6.x/7.x are those that don't take into consideration other Gecko-based products. If they want a same-looking interface everywhere, then I can only suggest that they rather make distinctions between Gecko versions where necessary and not concentrate on a specific browser product version (like Netscape 6.x/7.x) unless that specific [stable] browser product version is at fault. Netscape announced it was to abandon Netscape Navigator after the Mozilla Foundation announced it would abandon the Mozilla Suite ("Seamonkey"). Some weeks ago, the Mozilla Foundation changed its agenda: Mozilla Suite would continue to exist. Now, Netscape says it will relase another Netscape Navigator. Does anyone still doubt Nestscape's Navigator future is tightly tied to Mozilla Seamonkey? Conspiracy theories sound so good, but this one is completely inaccurate. We decided to continue a focus on SeaMonkey because it became clear that there is a significant group of people who care about it. This includes a large number of distributors who contribute resources, as well as institutional deployments. Mitchell I didn't mean the Mozilla Foundation resumed Seamonkey development because of Netscape leaving Navigator, but the exactly opposite: Netscape would resuming Navigator development because the Mozilla Foundation is not giving up with Seamonkey. An that is a problem why? IMO it would be a bad idea for AOL/Netscape to release a version of Firefox & Thunderbird under the Netscape name, simply because it is not what people are expecting. Even more so for a point release. AOL saw they had an chance to update the technology in Netscape without causing too much distruption so took it. No; Firefox would have been fine for "Navigator"; they could just have recombined Firefox and Thunderbird to recreate the Netscape suite if they'd wanted to. My goodness-----why not just produce one browser package and be done with it? 3 different browsers that all essentially do the same thing------now that's redundant, isn't it? I'm not on the "inside"----just an observance from the "outside." 3? You mean 9, right? (Netscape, SeaMonkey, Firefox, K-meleon, Galeon, Beonex, Epiphany, AOL on Mac, Compuserve, at the very least.) Yeah, I spend nights wondering why all those people are taking the same rendering engine and writing different (or not-so-different) browsers around it... We should scrap them all and just have a single Gecko-based browser. That should probably be K-meleon, right? #20 Re: Re: How many Mozilla browsers do you need?by leafdigital Wednesday March 31st, 2004 1:22 AM *giggles* (ok, so I felt like making a totally helpful post. but thanks for the reality check, funny) Well, I was thinking only of Mozilla, Firefox, and Netscape. Those are the big-boys that I know of.....I tried Galeon about a half-year ago and thought it was woefully behind the others. I think if the efforts could be more concentrated that might speed up the development of an end-product and also give better opportunity to produce a superior product with more resources/humans working towards the same goal. But who am I? I'm just an end-user.....not a developer. :) I take that back....I never tried Galeon----it was K-Meleon that was less than impressive-----no tabs (layers only---yuck!). Can anyone really like K-Meleon as much as Firebird or Mozilla for full-featuredness capability/potential? Well, K-Meleon was specifically tailored to and have its interface through Windows API's and just have a Gecko rendering engine. This would be similar to having Netsape 4.x without its old rendering engine and having the Gecko rendering engine instead — though this didn't exactly happen like that. Half a year ago, K-Meleon was not so good, but its 0.8.2 version is the best that one could get from K-Meleon. The problems with K-Meleon are that it's not yet a browser from which to expect too much, in that it is somewhat raw. The good thing though is that it's usable and fits very well for older computers /like the Pentium 120 with 32M RAM that I'm currently using to write this. Compared to K-Meleon 0.8.2 in that machine, Mozilla Firefox 0.8 is a full-fledged bloat. The three browsers you mention are worked on by three orthogonal sets of developers. If one of them stopped development, those developers wouldn't switch to the other ones. So I'm not sure how concentrating effort should be accomplished. My post was totally serious. It's just like proposing that all Epiphany developers switch to developing Firefox instead. They'll just laugh at you. Hi, nice to know now that 1.7 will be a stable branch replacing 1.4 :-( So I must be faster in the MNG question http://bugzilla.mozilla.org/show_bug.cgi?id=18574 Hope for all Help. Thx. I don't think there's much chance of that happening. Anything that isn't low risk and/or a critical fix is unlikely to get approval to go in at this point... 1.7 as the next stable branch seems a bit rushed. Everybody seems to agree on that, even though some think it can be pulled of anyway. Sticking with the tradition-of-excellence that Mozilla as acquired in the past two years, in my opinion it may be reasoable to wait. 1.7 has some great fixed to Gecko and possiblt mng can be restored in time, both changes that would make sense for the next stable branch. Why not declare now that 1.8 will be stable and then have Frefox wait with 1.0 for the 1.8 branch and let AOL do what they want to do (and if they are smart, they would also wait, possibly opting for a simultainious release as they have done before). Since they are not contributing to the Mozilla project anymore, nobody should feel the need to rush things for AOL. And Firefox is better off a month late and on a stable branch then on-time and on half-hearted-stable-branch. Just my 2cents. Keep up the great work! Why not AOL make a beta of its new release of Netscape out of the rushed 1.7 and then a stable version out of 1.8? Firefox 0.9 could be also made out of the rushed 1.7 and then Firefox 1.0 made out of Mozilla 1.8. The same, IMHO, should also apply to all other projects that have not yet had a 0.9 release even. > Why not AOL make a beta of its new release of Netscape out of the > rushed 1.7 and then a stable version out of 1.8? Looks like this or something like this indeed happened after someone gave a link to Daniel Glazman's blog ( http://webperso.easyconnect.fr/danielglazman/weblog/index.php/2004/03/30/242-ANewMozillabasedVersionOfNetscapeReleasedByAolThisSummer#c1479 ): http://navigator.netscape.com — see navigator.netscape.com Ok, I have direct and reliable information about this news report and it seems to be totally confirmed (just to mention it, no, it's not a 1st of april joke and even if I am in Europe, we're not the 1st of April yet here). So there is ONE IMPORTANT AND ONLY ONE hint we really miss about this: who's behind??? I mean who at AOL took that decision... Politically, inside AOL, this is tremendously important. Not anyone has the will and the power to go against David Gang. What's going on there? Is someone at AOL preparing the future away from the TimeWarner umbrella? I really wanted this. I cannot accept AOL not supporting the Netscape browser. I've posted to my blog on the subject. I hope this is true (I don't know how well to trust this source). Conversation in AOL HQ: Exec 1: Hey, about the decision we made to let the mozilla folks fare for themselves, dump the netscape browser, and drive the Netscape name into the dirt? Exec 2:Yeah? #1: Well, this "Kovu" guy says it's simply not acceptable. #2: STOP THE PRESSES! RE-HIRE THE UNEMPLOYED FORMER MOZ DEVS! DONATE THE NETSCAPE TRADEMARK TO THE MOZ FOUNDATION! I still think it was not so nice of them to fire the Netscape team and then keep using their talents -- at no cost. interesting info: http://glazman.org/weblog/index.php/2004/03/30/242-ANewMozillabasedVersionOfNetscapeReleasedByAolThisSummer#c1479 |