AOL to Release New Netscape Update in Early Summer
Tuesday March 30th, 2004
The 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.
#1 Good News
Tuesday March 30th, 2004 11:07 AM
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.
#2 New stable branch?
Tuesday March 30th, 2004 12:48 PM
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.
#3 Re: New stable branch?
Tuesday March 30th, 2004 1:00 PM
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.
#7 Re: Re: New stable branch?
Tuesday March 30th, 2004 2:48 PM
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.
#9 Re: Re: Re: New stable branch?
Tuesday March 30th, 2004 3:58 PM
> 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.
#11 sick to your stomach?
Tuesday March 30th, 2004 5:30 PM
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.
#62 Re: Need help? Do it yourself
Monday April 5th, 2004 7:15 PM
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?
#42 Re: Re: Re: New stable branch?
Thursday April 1st, 2004 12:27 PM
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...
#43 Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 1:14 PM
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.
#52 Re: Re: Re: Re: New stable branch?
Friday April 2nd, 2004 6:21 AM
> 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).
#12 Re: Re: New stable branch?
Tuesday March 30th, 2004 5:34 PM
"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.
#14 Re: Re: Re: New stable branch?
Tuesday March 30th, 2004 7:41 PM
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?
#34 Re: Re: Re: Re: New stable branch?
Wednesday March 31st, 2004 11:30 PM
"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.
#35 Re: Re: Re: Re: Re: New stable branch?
Wednesday March 31st, 2004 11:54 PM
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. :-\
#36 Re: Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 6:18 AM
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.
#44 Re: Re: Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 1:58 PM
"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.
#45 Re: Re: Re: Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 2:57 PM
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".
#47 Re: Re: Re: Re: Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 4:10 PM
Amen. That seems to sum up what's going on absolutely perfectly.
#48 Re: Re: Re: Re: Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 7:06 PM
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.
#51 Re: Re: Re: Re: Re: Re: Re: Re: Re: New stable bra
Friday April 2nd, 2004 2:03 AM
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.
#53 Oh, an overloaded word ...
Friday April 2nd, 2004 7:04 AM
I think I get it ...
stable (1) adj: Does not crash in use. stable (2) adj: APIs do not need to change to accomodate functional extensions.
#46 Re: Re: Re: Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 4:09 PM
> 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).
#49 Re: Re: Re: Re: Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 7:24 PM
"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.
#50 Re: Re: Re: Re: Re: Re: Re: Re: Re: New stable bra
Thursday April 1st, 2004 8:13 PM
> 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.
#55 Re: Re: Re: Re: Re: Re: Re: Re: Re: New stable bra
Friday April 2nd, 2004 1:22 PM
"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.
#61 Re: Re: Re: Re: Re: Re: Re: Re: Re: New stable bra
Saturday April 3rd, 2004 9:33 AM
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.
#38 Re: Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 6:24 AM
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."
#39 Re: Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 6:28 AM
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.
#40 Re: Re: Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 6:30 AM
(Boris posted as I was writing this)
#41 1.7 quality
Thursday April 1st, 2004 6:34 AM
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.
#4 Re: New stable branch?
Tuesday March 30th, 2004 2:04 PM
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.)
#6 Re: Re: New stable branch?
Tuesday March 30th, 2004 2:40 PM
Ah yeah now I see it. I didn't click the full article for the previous mozillazine post. It's even the first sentence. Why they didn't put that in the content of the post that appears on the home page is beyond me. That's a major point to miss.
#5 Switch to Firefox already!!!
Tuesday March 30th, 2004 2:23 PM
Switch to Firefox already!!!
#8 Re: Switch to Firefox already!!!
Tuesday March 30th, 2004 2:56 PM
I have to concur :)
#18 Re: Re: Switch to Firefox already!!!
Tuesday March 30th, 2004 10:18 PM
> 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 :)
#22 Re: Switch to Firefox alrea
Wednesday March 31st, 2004 4:45 AM
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..."
#56 Gecko /was: Re: Re: Switch to Firefox alrea
Saturday April 3rd, 2004 1:52 AM
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.
Saturday April 3rd, 2004 1:53 AM
Now I learned that I actually have to have three carriage returns to separate paragraphs. I'm probably not the only one to not make use of simple features just after they're released.
#32 Change the UA already!!!
Wednesday March 31st, 2004 8:18 PM
We, the "Mozilla community", know that if it works with Netscape 7.x then it will work with Firefox. But since the poor benighted MBNA's of the world can't seem to figure that out, let's give them a clue by putting the compatible Netscape version into the default UA string.
#10 Navigator tightly tied to Seamonkey
Tuesday March 30th, 2004 4:17 PM
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?
Tuesday March 30th, 2004 5:48 PM
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.
#17 Re: SeaMonkey
Tuesday March 30th, 2004 9:21 PM
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.
#21 Re: SeaMonkey
Wednesday March 31st, 2004 3:40 AM
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.
#26 Not relevant
Wednesday March 31st, 2004 11:29 AM
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.
#15 How many Mozilla browsers do you need?
Tuesday March 30th, 2004 8:52 PM
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."
#16 Re: How many Mozilla browsers do you need?
Tuesday March 30th, 2004 9:17 PM
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?
Wednesday March 31st, 2004 1:22 AM
(ok, so I felt like making a totally helpful post. but thanks for the reality check, funny)
#30 Re: Re: How many Mozilla browsers do you need?
Wednesday March 31st, 2004 5:58 PM
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. :)
#33 Re: Re: Re: How many Mozilla browsers do you need?
Wednesday March 31st, 2004 8:22 PM
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?
#58 Sporadic K-Meleon user
Saturday April 3rd, 2004 2:10 AM
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.
#37 Re: Re: Re: How many Mozilla browsers do you need?
Thursday April 1st, 2004 6:20 AM
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.
#19 new stable branch?
Wednesday March 31st, 2004 12:24 AM
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.
#24 Re: new stable branch?
Wednesday March 31st, 2004 8:52 AM
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...
#23 Wait for 1.8
Wednesday March 31st, 2004 5:12 AM
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!
#59 Re: Wait for 1.8
Saturday April 3rd, 2004 2:16 AM
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.
#60 Re: Re: Wait for 1.8
Saturday April 3rd, 2004 2:23 AM
> 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
#25 what really matters: who's guilty...
Wednesday March 31st, 2004 11:10 AM
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?
#27 Thank God
Wednesday March 31st, 2004 11:33 AM
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).
#28 Re: Thank God
Wednesday March 31st, 2004 1:18 PM
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!
#29 Re: Re: Thank God
Wednesday March 31st, 2004 2:34 PM
#31 grrrr I dislike AOL
Wednesday March 31st, 2004 6:12 PM
I still think it was not so nice of them to fire the Netscape team and then keep using their talents -- at no cost.
#54 Re: what really matters: who's guilty...
Friday April 2nd, 2004 10:51 AM
interesting info: http://glazman.org/weblog/index.php/2004/03/30/242-ANewMozillabasedVersionOfNetscapeReleasedByAolThisSummer#c1479