Mozilla Firebird 0.6.1 Coming Soon
Wednesday July 23rd, 2003
In a posting to his weblog, Asa Dotzler discusses the forthcoming Mozilla Firebird 0.6.1: "We're planning on doing a Firebird release based on the Mozilla 1.5a branch. This isn't going to be Firebird 0.7 since we haven't met our goals for features and fixes but we think it's important to get the autocomplete crash fix (and a few other fixes) into the hands of all the people currently using 0.6.
#11 Re: Agree..
Thursday July 24th, 2003 8:31 AM
You are replying to this message
excerpt from <http://www.mozillazine.or…articles/article2031.html> :
First off, here are some terms you should know:
CVS: the location of the Mozilla source code. tree: a set of files in CVS. the Mozilla source code. pull: to check out a tree from CVS. check in: to update files in CVS with newer versions that have bug fixes. trunk: the primary or main-line set of files in CVS where code is worked on. tip: the most up to date files in the CVS trunk. tag: a set of markers across files that allow for a pull of the files as they were when the tag was made. branch: a copy of trunk files, hosted in cvs.mozilla.org, that can be developed independently of the trunk. cut a branch: to copy files making a branch. freeze: a period when the tree is not open for checkins or when checkins must first be approved. fork: a copy of the source code, hosted outside of cvs.mozilla.org, that diverges significantly from the trunk.
So How Does Mozilla Development Work?
As most of you all know, mozilla.org makes "builds" from the Mozilla source code several times a day. These daily (or nightly) builds are the result of a "pull" of sourcecode from the server cvs.mozilla.org. Regular nightly builds are pulled from the "tip" of the CVS "trunk". This means that these builds include all of the most recent changes "checked in" to the CVS tip. We stop development each morning and create these builds to test the previous day's changes, verify that check-ins actually fixed bugs and identify any new problems created in the last day's work.
About every 5 weeks <email@example.com> steps in to moderate risk for a few days on the development trunk and works to create a short-lived code "branch" from the trunk. All check-ins to the trunk during this "freeze" require approval from <firstname.lastname@example.org>. As soon as we have a build that is stable and we have a handle on the handful of bugs that we've identified as most important to the Milestone, a branch is created. This code branch can be thought of as an independent copy of the code on the trunk at the moment of branching. As soon as the branch is "cut", the trunk is opened to development so developers no longer have to ask drivers for approval to check in changes. A few developers working with <email@example.com> try to get fixes for the Milestone show-stopper bugs and get them checked in to the branch. During this work the majority of developers have returned to focus on the tip of the trunk. When drivers are satisfied that the Milestone branch is ready for consumption, a release tag is made on that branch. This tag is a marker on all of the files that need to be used in making the Milestone build. A build is made from that tag and released and the few people that were working on that Milestone branch return to work on the trunk. And that's the basics of Mozilla trunk and branch development.