Mozilla 1.1alpha PlansThursday May 30th, 2002David Baron has posted a Mozilla 1.1alpha update to netscape.public.mozilla.seamonkey. He notes that the release has slipped a bit due to work on the 1.0 branch and that drivers@mozilla.org is anxious to prevent any further delays. Therefore, the freeze for 1.1alpha will occur at midnight Pacific Daylight Time on Wednesday 5th June. The Roadmap has been updated to reflect the slippage. The roadmap is nice, but what exactly is going to be included in 1.1? A few layout fixes, a bunch of perf improvements, especially for pages that animate stuff via JS, download manager, probably a number of other things I can't think of offhand... With most of the devs working on getting 1.0 out the door, has there been substantial development work on the trunk? Enough to warrant a release? Also, according to the roadmap, 1.1 will be due sometime in the summer. Now we have the 1.0 branch and 1.1 branch. How are these related? Which one will mozilla.org recommend to distributors to package? For all practical purposes, when 1.1 comes out, the 1.0 branch will be useless - sure its long lived and would have the benefit of more testing, but normal users aren't going to know that, they're gonna go for 1.1. Is 1.1 even targeted for users? Do people know this? Seems like the 1.0 branch would be for NS, Redhat, and those others wanting to ship something stable. Should we (users) then shift our focus towards 1.1 bugtesting? It just seems that the release schedule would look something like - 1.0, 1.1alpha, 1.0.1, 1.1alpha, 1.1beta, 1.1, 1.0.2, 1.2alpha, 1.0.3. that makes no logical sense from the user perspective. Just like if Mozilla.org would have released 1.1alpha today, everyone would be scratching their heads wondering how that came before 1.0! If someone could bring some light to this issue I'd appreciate it. I'd imagine we could expect 1.0.x releases quite often to begin with and then the thing to remember is that "normal" users (for whom strictly speaking Mozilla isn't aimed at anyway so there really isn't much need to contemplate half of this stuff as the intended audience is more clued-up) wouldn't usually run ALPHA or BETA software anyway, so the first 1.1 release that will appear on their radar will be 1.1.0 and that is quite a way into the future, so it could all pan out and make sense in the end even judging by a more common-place software release schedule (this method isn't so uncommon, Audacity (cross platform audio editing software) is about to concurrently release 1.0 and 1.1 BETA. and OpenOffice.org have a development release (build 642x) that is ahead of 1.0 (build 641x) released ahead of 1.0) The 1.0 branch is designed to be a stable branch that vendors can work from. It will have new releases (1.0.1, 1.0.2 etc.) that will mainly be critical fixes. The trunk will be developed parallel to the branch with milestones being released every quarter or so (with preceding alpha and beta releases). As most of the development work will continue on the trunk, testers should concentrate on that (particularly after 1.0 is released). Though it is theoretically, possible that 1.1alpha could be released before 1.0, it probably won't be. Average end users aren't going to be using Mozilla (they'll use Netscape or whatever) so they don't really have to worry about the difference between the 1.0.x (branch) and the 1.x (trunk) releases. Alex New Netscape 4.x's have continued to appear long after the release of Netscape 6.0. Though maybe confused at first, users should be able to wrap their minds around the idea of new Mozilla 1.0.x's even after Mozilla 1.1 and Mozilla 1.2 ... Think of the Mozilla 1.0.x releases as mozilla.org's tried and true Classic Series and Mozilla 1.x's as the cutting edge (try it only if you dare) hope of the future! "With most of the devs working on getting 1.0 out the door, has there been substantial development work on the trunk? Enough to warrant a release?" According to the roadmap http://www.mozilla.org/roadmap.html : "As we do not intend to promote alpha and beta releases for uses other than testing, we will ship those releases according to the predetermined schedule, and let the chips fall where they may." So take 'alpha' and 'beta' as fair warning ;-) I've created a group bookmark consisting of pages on 6 tabs. The bookmark group loads fine, but then the CPU usage of mozilla.exe is always about 20-25%, even though I am doing nothing with Moz (or even if it is obstructed from view by other apps or minimized). I understand that there maybe animations running or flash movies or whatever, but they should be turned off when mozilla is either completed obstructed from view or minimized. Or is the cause of this problem something else? I am using WinNT on p3/600mhz How is this related to this thread? You are better off posting such in the forums. That will provide you with better results. Will the calendar be part of nightly releases once 1.0 is out. There was discusion about this when the calendar project was first launched. I for one would be very interested in testing and using the calendar. >> I for one would be very interested in testing and using the calendar. Knock yourself out: http://www.mozilla.org/projects/calendar XPI install available, works with nightlies. I have nothing but praises to the developers of Mozilla, but I gotta say that Mozilla crawls, as compare to opera or lynx. I hope that the 1.1 branch will drastically speed up the Mozilla perf. Let's hope that someone will finally get Mozilla to really perform ! I understand that the next release can't be a 1.0.1, then 1.0.2, etc as these are maintenance releases on 1.0. But why not go for a 1.1.0, 1.1.1, 1.1.2 until stable enought and then call it 1.2 .... Some people might assume the 1.1 would be a major new release, which it isn't, just of bunch of bug fixes and performance enhancements if I have followed correctly. Seems to mee confusing to have 1.1, 1.2, 1.3 out soon after each other without having major changes (like an included Calendar for example). Also, it is very hard to know what will be in new releases. It would be nicer if one could see when to expect what. New functionality is included by announcing a fix for the bug number of the feature request, but there is no HTML page of what to expect when, only when to expect "1.1", "1.2", etc. whatever this might mean for an end-user. The release numbering and roadmaps suggest that the mozilla team is on some schedule and has a plan. However over the past two years since netscape 6.0 was released, there have been frequent releases of roadmaps and each time 1.0 was pushed ahead a few weeks/months to catch up with reality. Now we have a situation that 1.1alpha was originally planned about two months after 1.0. The only problem is that the estimated date for 1.0 was, once again, moved on a bit. Realistically, if 1.1 alpha is frozen right now, it is going to be a pretty uninteresting release. I'd say forget about the roadmap and push out 1.0 ASAP and then create a new roadmap with a bunch of unstable releases to add new features. Users now have a solid release to use for a while so there's no point on insisting on stabilizing the development build even before the previous version is released. Wait for the reviews of mozilla 1.0 and netscape 7.0, reflect on that for a while and set some new development goals and then after a few months come with a 1.1alpha "Realistically, if 1.1 alpha is frozen right now, it is going to be a pretty uninteresting release. " Either you misunderstand what the 1.1alpha, beta and final cycle will look like or you're of a very different opinion than the people working to make these Mozilla Milestones happen. If you do understand the release cycles then I take exception with your definition of uninteresting. We've fixed nearly 2000 bugs in the 1.1alpha cycle, over 1000 that were not also fixed on the 1.0 branch. We've taken new features including "download manager", "view HTML mail as plaintext", "quote original message", windows and linux accessibility improvements, and much more http://bugzilla.mozilla.org/buglist.cgi?bug_id=,58311,69295,137440,90368,126082,135395,108153,60811,76099,49721,122524,139344,138242,78270,133366,139334,69529,70478,123563,30888,98476,97055 covers a handful of them. And we've taken heavy lifting changes, redesigns, rewrites and other major landings like the reflow coalescing and XUL fastload performance changes and more http://bugzilla.mozilla.org/buglist.cgi?bug_id=,129115,139471,112064,92033,135395 lists a couple of those. All of these changes warrant Milestone testing. The people working hard to implement and test these changes do consider them interesting and the companies shipping products based on Mozilla technologies also consider them interesting. "Users now have a solid release to use for a while so there's no point on insisting on stabilizing the development build even before the previous version is released." (You've contacted all of organizations and individuals using and shipping Mozilla-based products and none of them are interested in something stable with the many changes mentioned above?) Spending months and months in an unstable state is neither good for our code, our distributors/vendors nor good for our testing community. We've been doing this for a few years now and have a pretty good idea about how quickly we can integrate and test new changes. The cycles in the roadmap reflect our collective experience developing, testing and delivering our technologies so it is unlikely that they're going to be tossed aside because someone is of the opinion that 1.1 is uninteresting. Armchair project management is easy. If you think that you can put together a project that will have greater success then be my guest. Untold numbers of contributing organizations and individuals await your instructions. "Wait for the reviews of mozilla 1.0 and netscape 7.0, reflect on that for a while and set some new development goals and then after a few months come with a 1.1alpha" Wait for months? Just sit around and do nothing for months until c|net gets a copy of Netscape 7? What you fail to realize or acknowledge is that we've been working on 1.1alpha for a while now, taking thousands of checkins. We did reflect, for many months. We reflected on 0.9.6 and 0.9.7 and 0.9.8 and 0.9.9 and 1.0RC1 and 1.0RC2 and 1.0RC3, all the while making decisions to push certain features and other heavy lifting out to 1.1. Now we've taken those large changes and new features in 1.1alpha and they need to be fully tested in a Milestone. If now is too soon for you then you can ignore the release of 1.1alpha and 1.1beta milestones and not look again until we're at 1.1final. If we're moving too fast for your taste and you really want to be surprised by a new and exciting product then maybe you should ignore all the Mozilla Milestones and wait for Beonex 1.0 or Netscape 8. Users of these products can be surprised when they ship with a bunch of new features. It's much harder for Mozilla testers who can see changes as often as many times a day. Release early and release often. We've been doing it since the beginning and we'll continue to do so. There have been more than enough interesting changes to get builds out to a wider testing audience and collect the kind of expanded feedback that we get from Mozilla Milestones. --Asa Woo, asa! Kicking ass! :) I'm already looking forward to 1.1. It can't come soon enough as far as I'm concerned. Especially reflow coalescing. I finally want to be able to have a browser discussion with an IE6 user without at some point having to bow in shame and admit that his browser kicks my browser's ass speedwise. Keep up the great work! The number's aren't confusing if you follow development - they make sense for devs and those of us that follow other OSS projects, they just seem confusing for the average surfer. I just think it needs to be made clear, either on the start page, release notes, or wherever. For example, kernel.org has something like "The latest stable release is 2.4.18, the latest development release is 2.5.16" or whatever. That way, I can send mom and dad to 1.0 branch, and those that want to continue to test goto 1.1.
You're right! The www.mozilla.org homepage should have a small box in the upper righthand corner that makes it easy for the casual web user to know which build he should download. With the coverage of the 1.0 release, a lot of casual surfers will be stopping by www.mozilla.org, and we should make it easy for them to figure out which build they should download. You're right! The www.mozilla.org homepage should have a small box in the upper righthand corner that makes it easy for the casual web user to know which build he should download. With the coverage of the 1.0 release, a lot of casual surfers will be stopping by www.mozilla.org, and we should make it easy for them to figure out which build they should download. #20 Re: Excellnt suggestion! In corner of Mozilla homepageby bzbarsky Friday May 31st, 2002 2:38 PM There is just such a box in the bottom right corner, with one-click links to builds for most of the supported OSes. If some of the people in this forum who have followed Mozilla for years are confused by Mozilla's numbering system, then think how much worse it will be when Mozilla 1.0 is released and lots of total newbies decend on the site. Yes I know "Mozilla is not for endusers", but that dosen't mean that there won't be a lot of them anyway. Why not have a link on the site explaining what the numbers mean. Something like the first digit means a major release, second digit an upgrade to an earlier release, third digit means a bug fix to an earlier release. Oh, since I bought up first digits, I'll ask the question, is there any plan to branch for Mozilla 2.0 for some hard core expermental code for the next major release? `is there any plan to branch for Mozilla 2.0 for some hard core experimental code for the next major release?' Mozilla-related questions beginning with `is there any plan to ...' (or `are there any plans for ...') are usually meaningless, and this one is no exception. Branches for x.0 versions of Mozilla happen about once every three years. Branches for `hard core exper[i]mental code' happen all the time. Obviously, they're never the same branches; that would be silly. -- mpt |