Mozilla 1.4 to Feature Reorganised Release NotesThursday June 26th, 2003Asa Dotzler has announced that the Mozilla Release Notes are to be reorganised and given a partial rewrite. Referencing Zach Lipton's recent thoughts on the matter, Asa describes how the release notes will be divided into several files, including a what's new document, an installation guide and a list of known issues. A lot of the older and less important information will also be removed. It is hoped that these changes will be made in time for the release of Mozilla 1.4 on Monday. finally. I hated the old release notes. Seemed like an do all document where you never find what you are looking for. The What's New section has been very confusing, and I hope to see a change. It should list by milestones the changes that have occurred, in the same way every other product uses What's New. Right now, what happened since 1.3 is lumped together there. It should list the major changes from 1.4b -- the last milestone -- to RC3. "Right now, what happened since 1.3 is lumped together there. It should list the major changes from 1.4b -- the last milestone -- to RC3." No, it shouldn't. The 1.4 release notes should list all of what's new since the last official release which was 1.3.1. The overwhelming majority of people who will read this (when we ship Mozilla 1.4) didn't read the alpha, beta and release candidate notes or test any of those builds. Starting with the first release candidate, the release notes are treated as 1.4 release notes and are meant to be tested and debugged just like the release candidates in preparation for 1.4 final. --Asa that's a fair point with the release candidates, but there are plenty of people that want to know what changes between betas, alphas and "final" releases - the question gets asked repeatedly in various forums every time there's a release. and who are all these people that are just using the "final" releases? all the binaries are only made available for testing purposes anyway - we don't support "users" :) "there are plenty of people that want to know what changes between betas" That's exactly how it works. Major changes happen in alpha and beta. Few changes happen in the final (and rc) cycles. The what's new section highlights _some_ of the important features or major bugfixes that were landed between, for example, 1.3final and 1.4alpha http://mozilla.org/releases/mozilla1.4a/#new, and 1.4alpha and 1.4beta http://mozilla.org/releases/mozilla1.4b/#new . The 1.4final release notes, what's new section, will highlights the impoortant or high-visible changes (mostly features) that happened between 1.3final and 1.4final http://mozilla.org/releases/mozilla1.4/README.html#new . This isn't a changelong. If it was it would be nearly 2,000 items long. If you want that you can ask bonsai or bugzilla. "and who are all these people that are just using the "final" releases?" You could just as well have asked "Who are these people using alphas and betas when nightly builds are where the real effort happens." or "Who are all these people testing mozilla.org-produced nightly binaries when the real work comes from people that build themselves." Who are they? They are hundreds of thousands, maybe millions of people that want to download the Mozilla suite of applications. They provide invaluable feedback through bug reports, talkback and comments on weblogs like MozillaZine and Slashdot. Mozilla benefits immensely from all of the feedback we get at all levels from people making their own builds, to nightly build testers to users of milestones, alpha, beta and final. The better job we do expanding all of those pools and building even better feedback mechanisms, the better Mozilla gets. --Asa You're quite right on the "this isn't a changelog" thing. I actually gave a similar answer myself a few days ago when someone asked a similar question. Dunno what I was thinking... The second point wasn't entirely serious... but I'm not sure how much useful feedback we are getting from those folks. I'm not sure the pools do need expanding, but we do need better feedback mechanisms. Currently the primary 'official' feedback mechanism is bugzilla, and even if people can figure out how to use it, most bugs don't even get looked at by a QA person, let alone a developer. The forums have some useful feedback in them, but there's no guarantee that it gets seen by anyone that can do anything with it... I should've made it clearer. I meant there should be something like this: Changes in 1.4RC3: blah Changes in 1.4b: blah blah blah blah blah Changes in 1.4a: blah blah blah blah >I should've made it clearer. I meant there should be something like this: >Changes in 1.4RC3: blah >Changes in 1.4b: blah blah blah blah blah >Changes in 1.4a: blah blah blah blah Except that this isn't a changelog. If it was it would be between 1,000 and 2,000 items long. The what's new section of the release notes highlights new features or major bugfixes. If we're sticking to the roadmap, new features and major changes aren't happening in the final (or rc) cycles. Other than not having anything new in the what's new section for final (and release candidates when we have them) we have exactly what you want. The what's new in 1.4a was the feature-like stuff that happened in alpha and the what's new in 1.4b was the feature-like stuff that happened in beta. --Asa |