Mozilla 1.7 to Become New Long-Lived Stable Branch
Friday April 2nd, 2004
In a newsgroup posting, Asa Dotzler has announced that the Mozilla 1.7 branch will become the new long-lived stable branch, replacing 1.4. The stable branch is intended to act as a baseline for developers building Mozilla-based products, with critical bugs fixed on the branch as well as the trunk.
Mozilla Firefox 1.0, a new milestone of Mozilla Thunderbird, a new Camino release and several third party Mozilla based products will be based on Mozilla 1.7, so the Foundation is making efforts to ensure that it is high quality. To do this, the branching of 1.7 from the trunk has been delayed by a week to Friday 9th April and the final release of Mozilla 1.7 has been moved out a month to mid-May. Between the branching and the final version, three release candidates of Mozilla 1.7 will be made available, much like there were for Mozilla 1.0 and Mozilla 1.4. These release candidates will ensure that the 1.7 branch gets more testing and QA work.
While most welcome the fact that the aging 1.4 branch is to be replaced by something more modern, some developers have expressed concern that the decision to use 1.7 has been made so late in the release cycle.
So will this be what the new netscape uses?
Perhaps there should be a 1.7c before there are any 1.7 release canidates to allow for more changes before the stable release.
Unfortuantely, for some changes that I really think should go on the api-stable branch we'd need an alpha/beta/stable cycle... or at least a beta/stable cycle.
I sure hope so, Mozilla 1.7 sure has some cool features. Anyway, didn't stable versions of Mozilla usually had even numbers at second part of their version number, eg. 1.0, 1.4, 1.6?
1.6 wasn't an api-stable branch. The only api-stable branches we've had so far were 1.0 and 1.4.
Boris, after reading through the 'AOL/Netscape' thread, I dont understand why an api-stable branch, and a crash-stable branch for embedders, other projects need to be the same one..
Frankly, why should firefox / thunderbird / camino / netscape care that some APIs in 1.7 are half baked, and functionality will change again before the next stable release, which should be sometime mid next year? What is the gaurantee that if 1.8 was the stable branch, APIs would remain stable for another year?
Basically, what I see is that you're advocating a developer-oriented release schedule instead of a consumer-oriented one.
> I dont understand why an api-stable branch, and a crash-stable branch for embedders, other projects need to be the same one..
Because embedders need to use the APIs? The whole point of a stable branch is not just that it is maintained, but also that it is the recommended base for people to build on.
In principle, there's no reason why Firefox needs to launch from an embedding-stable branch except that they will probably want to release security updates for 1.0 and only embedding stable branches are maintained.
> Basically, what I see is that you're advocating a developer-oriented release schedule instead of a consumer-oriented one.
That depends on who you consider the consumers of gecko to be. If you think of the consumers of gecko as being random members of the public who use Firefox and don't care about the internals at all, then that's a fair point. If you consider the projects which actually use gecko (not just mozilla.org sponsored projects but also people like <http://www.redbacksystems.com/projects/mozngw/> and <http://www.gnome.org/projects/epiphany/> ) to be the consumers then it makes sense that one should require decent interfaces in one's stable releases.
> What is the gaurantee that if 1.8 was the stable branch, APIs would remain stable for another year?
None. ;) It's a matter of what the apis are on the stable branch though.
And there is no reason you can't have an api-stable branch different from the crash-stable branch apart from the resources needed to create two crash-stable branches and the fact that security fixes are typically only ported to api-stable branches. And the fact that drivers have decided that 1.7 will be the api-stable branch, of course.
#6 Oh well, decisions been made.
Saturday April 3rd, 2004 12:14 AM
Sad but true, 1.7 with half-hearted API changes and planned changes not in yet will be the first mozilla product to break a wonderful tradition of high quality software, not only for users (crash stability, which may be fixed by the final release) but also for developers (api-stability, which cannot really be fixed by now.) Also it will be the first "stable" branch to cut out MNG and JNG suppiort, so much for being ahead of other browsers.
This is sad.
Loosing MNG and JNG support is bitter. But for the uninformed, could you give more details on which API changes and planned changes are not in?
As 1.4.1 was the first stable browser of the 1.4 series, will there also be a 1.4.2, where the remaining issues are fixed?
There is a 1.4.2 for Redhat linux. I have it on my RH 9.0 at work. I got that from the up2date function of RH. But I have not seen a 1.4.2 officially from the Mozilla foundation. So I don't know what the deal is with that version.
#18 WMP 9 doesn't support scripting in Mozilla
Saturday April 3rd, 2004 8:20 AM
1.4.2 is done, builds should be released soon.
#12 when u coming back to the forums bro
Saturday April 3rd, 2004 2:43 AM
u are missed
#13 Re: when u coming back to the forums bro
Saturday April 3rd, 2004 2:44 AM
johann_p that is
#15 Lets hope these bugs, and others, will be fixed
Saturday April 3rd, 2004 3:29 AM
Chrome registration error: <http://bugzilla.mozilla.org/show_bug.cgi?id=235667>
Security related bug: <http://bugzilla.mozilla.org/show_bug.cgi?id=235457>
Why release a half-assed API as a "Long-lived Stable Branch"? Just for Firefox and Thunderbird? I don't see the need.
Sounds like AOL/Netscape still has a pinky-pinch on mozillla.org?
"Why release a half-assed API"
Where was your criticism for the "half-assed API" in the 1.4 branch? Where was your whining about the half-assed APIs of the 1.0 branch? Can you even name a single API that you consider half-assed in the 1.7 codebase that's worse than what we shipped and supported in 1.4 or 1.0? Can you list the frozen (or even non-frozen but critical) APIs of the 1.0 and 1.4 releases and describe with any coherence how the full set of APIs for 1.7 is "half-assed" compared to the full set of APIs that were supported in 1.0 or 1.4?
When you're delivering gecko to millions of users and you've got a specific list of APIs that don't meet the needs of the application you're shipping, and you're offering up the resources that would facilitate our maintaining stability branches for both the mozilla.org apps and your embedding app, then come back with your protests, and those resources in tow. Short of that, how about letting up with the uninformed accusations, some appreciation for the people that are actually being asked to do the work to ship gecko to millions of users, and some acknowledgment that while we don't have the resources to please everyone, we're working hard to do the most with what we do have.
Or, you can go on whining about "half-assed API" that you're not even taking the time to thoughtfully describe or criticize but don't expect me to sink any time into replying.
I would like to hear ASA's opinion on the API problems that are facing the 1.7 release. Sure, 1.7 is important for Firefox/TB/Camino but what about the 200million users of Sun's Java Server to be released in China?
What about extension developers and other devs who base their work (which feeds them and their family) off of mozilla.org products and the stable "long-lived" release?
Personally I feel like Asa and "drivers" are giving us the middle finger. I thought these problems had been delt with in the past. 1.6 was an awesome product, and 1.7 will be too. But you are WAY too late announcing 1.7 as a long-lived release.
I have a novel idea! Why not continue with this new plan of delaying 1.7 to mid march and shooting for 1.8 to be the stable-branch. That way, Fx/TB/Caminoa/etc. will all get the exact same "stable release" from 1.7. And yet other vendors will be able to decide if they shoudl wait for 1.8 or dive into 1.7 "knowing the risks". That would keep everyone happy, and let the devs be devs.
Boris: Please don't let this reflect on your involvement in mozilla/gecko/etc. There is still time for this to be corrected.
>Why not continue with this new plan of delaying 1.7 to mid march and shooting for 1.8 to be the stable-branch. That way, Fx/TB/Caminoa/etc. will all get the exact same "stable release" from 1.7. And yet other vendors will be able to decide if they shoudl wait for 1.8 or dive into 1.7 "knowing the risks". That would keep everyone happy, and let the devs be devs.
I think the issue with the vendors was that 1.8 would not be tested enough to assure crash-stability by the time they need to release. Perhaps we could just finish up 1.7 quickly as a normal release, then have a brief 1.8 cycle only for API changes and stability work. We could then do all the RC's and extra testing on 1.8 to make it the long-lived API stable branch, and it should be out in time for the vendors to use it. But it looks like things have been decided already.
This kind of thing should be part of the roadmap - instead we have an obsolete document (which talks about the 1.4 branch being in the future) on the website, and a bunch of ad-hoc announcements that contradict it. If Brendan doesn't have the time to do it, maybe someone else could help out? We could at least pull the old version down so it doesn't continue to cause confusion.
For some strange reason, the roadmap is always the last document to be updated. ;-) By the time it is updated, all the information has already been public in bits and pieces.
#28 Re: Re: roadmap
by naylor83 <firstname.lastname@example.org>
Sunday April 4th, 2004 5:58 AM
Yeah, I agree. What happened to the updated roadmap which was just around the corner at Xmas 2003, with Firefox additions? And after that it was around the corner when Firefox was released... and now? We still haven't seen it...
I do understand that Moz.org has a lot on it's (to few) hands, but I don't understand why they keep 'promising' things like this when they never deliver anything when they have said they will. Are they really this bad at estimating the time things take? They should stop claiming things like 'the roadmap will be out in so and so many weeks/months', and '1.0 will be out then and then'.
Then, otoh, this still isn't the end of the world exactly... Keep working, HARD! I love the Mozilla products!
"...(first on or around April 14, second on April 28th, and final on April 12th)..."
Should not the "April 12th" read "May 12th"?
None came. So Asa acted. Granted, he only waited (according to the Mozillazine article dates) for 4 days, and technically not 4, since the article wasn't posted for the entire day March 30th, but rather mid-day. (March 30th, 31st, April 1st, April 2nd).
If we are going to learn from this and perhaps change the organization's mind, we must understand whether Asa considered input for a reasonable amount of time and of the right people.
If we think this procedure was not appropriate, then we need a written procedure that is followed.
First, let's deal with understanding what was done.
Asa, were the embedders consulted?
What did they say?
Was their feedback taken into account?
I fall into the "use Mozilla products as shipped" category, so this does not matter to me personally. However, some people use K-melon, which actually is affected by the embedding stability of Mozilla products. (K-melon, however, has a history of waiting longer than we do before releasing new versions anyway. I think all consumer and enterprise versions of Mozilla such as Sun's are worried more about MTBF and backward-compatibility than with shiny new features.
Hope this makes sense.
#35 Re: Asa asked for feedback.
Monday April 5th, 2004 7:01 PM
"Asa, were the embedders consulted? .... I fall into the "use Mozilla products as shipped" category, so this does not matter to me personally. However, some people use K-melon, which actually is affected by the embedding stability of Mozilla products."
I don't think I've ever consulted the K-meleon developers about anything. I don't think they've ever consulted drivers either. I couldn't even tell you who they are. If they're interested in being involved with Mozilla planning, they should get in touch with us and we can talk. <email@example.com> isn't a top secret list.
Here is where the mistake lies:
>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. - quoted from Asa
If in November it looked like 1.7 or 1.8 and you knew that 1.7's release date would be near 1 year after 1.4 then you should have made a plan in November to make 1.7 the next stable release. If you told the other camps this information in November they probably would use the 1.7 branch even if their releases landed around 1.8 time. Did you not think to yourself "What happens if they branch of a non-api-stable 1.7 for FireFox 1.0"?
If people in charge want to pay me to build long term plans, I'm more than willing to offer my services.
If Firefox 1.0 becomes a crappy release (like Netscape 6) you may as well flush all the efforts we've made since Mozilla 1.0 down the drain.
Firefox 1.0 will be just fine. It certainly won't be anything like Netscape 6.
Nothing will be overtly broken as a result of this decision -- things just won't be as good as they _might_ have been if there were some actual project management going on. Some embedding apps won't have the flexibility they might have had otherwise to get some things done, for example, but they've been living with that for a while now, I guess.....
Deal with it. Move on. Get it done. Slay the Microsoft beast.
something of a repost:
In a perfect world we'd have known that _all_ of the mozilla.org products (and other non-mozilla.org products) 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), considerably slower, missing some key new features, and it's about to be retired (no longer 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 releases and ship updates/point releases.
We have limited resources. A major hunk of our resources (pretty much all of the Mozilla Foundation paid staff) are going to be devoted to making 1.7 something that's stable, fast, functional, and useful to products delivering Gecko into the hands of millions of users. We cannot ship a lame Mozilla 1.7, a broken Firefox 1.0, hosed Camino or Thunderbird releases. All of those apps, bearing the name and reputation of mozilla.org must be of high quality and that's going to take some effort. They're also going to need to ship updates/point releases from that branch and that means the branch will need to be maintained. The math isn't too difficult. That simply doesn't leave us with resources to also maintain a 1.8 or a 1.9 long-lived branch for other embedders. If other embedders want to maintain a second branch, they can certainly contact drivers with a plan and information about the resources they're willing to commit.
I wish that things had come together months earlier and that we would have had more communication, but this is where we are. We have _all_ of the mozilla.org applications set to make important releases from the 1.7 branch. We have other products set to ship off of the 1.7 branch. These releases come at a pivotal time and will likely garner quite a bit of press (at least I expect that Firefox 1.0 will) so they really must be of high quality and I'm confident that they will be. Yes, we could have done a better job at getting this organized and communicated to the developers working on the core codebase. I'll accept some of the blame for this coming off less than ideally, though I am just one of about a dozen drivers from multiple organizations, so don't assume that because I'm the lucky guy that gets to post the news that I'm the only person involved in the decisions or planning.
If you've got an application that depends on APIs that you know are worse than they were in 1.4 or you know of bugs that make Mozilla 1.7-based products worse than 1.4-based products, how about spending some of your time delivering those specifics (even better if they come with patches) to <firstname.lastname@example.org> rather than complaining at mozillazine. This release cycle isn't over yet and there's still time to get some kinds of changes into this branch. If you've got resources to maintain additional Mozilla branches to meet your product needs, then how about sending mail to <email@example.com> rather than posting complaints at mozillazine.
For whatever reason, Asa, you seem to be missing the point. The point is not that 1.7 will be bad or that anyone is going to make it bad; on the contrary, everyone wants to see a good release. The point is that drivers should be making the decision about the stable branches significantly in advance and then publicizing that fact. It doesn't really matter whether the APIs are not any worse than they were in 1.4 or 1.0. They could have been significantly better, with an advanced warning. Drivers should have made the decision that 1.7 was going to be the stable branch and made Firefox, Thunderbird, and Camino make that work for them, not the other way around. You and the rest of drivers are letting the project be dictated without any timelines by three admittedly major Gecko implementors who just happen to be funded by the Foundation. The point everyone is trying to make is that the Foundation should be telling them when the stable branch should take place, not the other way around. If they needed features, they would've had months. At this point, all embeddors must live with APIs and core problems that might otherwise have been fixed.
Asa, don't listen to the negative voices.
The bottom line is that 1.7 is going to be really, really awesome. It will be a big step up from 1.4.
The other products like Firefox are going to benefit greatly from all the work going into 1.7.
Could the process have been better? Yes, but so what?
Asa, you're doing a great job, and you are not thanked enough.
Thank you, Asa, you're doing a great job.
asa, stick to your guns! 1.7b i already find better than 1.4.1, despite some small quirks that i am sure will be tweaked soon. what i see is that 1.7 is good choice for next stable branch. i also see that for a year from now, and extra couple months WARNING for the next branch could be very helpful for developers, but that is just a communication issue for the future. for now, stay with 1.7, and keep up the great work! thanx :)
(quote) We'll be scheduling three release candidates from the 1.7 branch, each 2 weeks apart, with room for more if needed (first on or around April 14, second on April 28th, and final on April 12th). This means moving the 1.7 final release date out 1 month from mid-April to mid-May. (end quote)
Shouldn't that be "May 12" for the final (sted April 12)?