Uncategorized

Branch diagram, including the new FF3.1 project branch

joduinn5 Comments

Last Wednesday, we setup the new Firefox3.1 project branch. (Details on the machine-setup work coming in a separate blog post.) Meanwhile, I thought people might find this diagram useful to help understand the repository cloning/branching work that happened.

Note:

  • To keep terminology consistent, last week we created a “project branch”. We’ll be creating “release branches” on this project branch for each milestone.
  • Before we allow checkins to the new mozilla-1.9.1 project branch, we will need to carefully cross-check all the changes landed on mozilla-central since the mozilla-1.9.1 branch was created (The area in the dotted circle) and verify that those changes were also landed on mozilla1.9.1.
  • We want the mozilla-1.9.1 branch to start from FF3.1beta2. To speedup opening the mozilla-1.9.1 branch, we branched early. This means that before we allow checkins to the new mozilla-1.9.1 project branch, we will need to carefully cross-check all the changes that landed on mozilla-central since the mozilla-1.9.1 branch was created (The area in the dotted circle), up to the branch for FF3.1beta2, and verify that those changes were also landed on mozilla1.9.1. Any later FF3.1beta2 respin would require patches to also be landed on mozilla-1.9.1.
  • There’s been discussions recently on whether we’d have a FF3.1b3 or not. I included FF3.1b3 in the diagram so that, if we do decide to do Beta3, people could see where it would be branched from. This is not meant to state or imply that we are doing Beta3! 🙂
  • The diagram above shows logical active-branches-of-code. At the SCM repository level, some of these active-branches-of-code are implemented as in-repo-branches, and some are implemented as separate-cloned-repos. For the sake of clarity, I’ve omitted those details in this post, but would be happy to go into further detail, if anyone is interested.

Hope that helps?

tc
John.

UPDATE#1: added extra text in 2nd bullet point, describing the cross-branch synchronization, to clarify how we branched and why.

UPDATE#2: Sam Sidler and and Gavin Sharp both pointed out that the branching diagram had an error when describing how FF1.5 was branched from FF2.0. They are correct, and I thank them. The branch diagram above has been updated, and is now correct. I since found the same error in a presentation we gave here at the 2008 Mozilla Summit (diagram had same error), and a brownbag in Mountain View office (diagram had same error).

5 thoughts on “Branch diagram, including the new FF3.1 project branch”

  1. To nitpick the branching diagram 😉

    The project trees (such as actionmonkey/tracemonkey) are not branches in the normal way: because they are frequently merging with -central, it’s more like:

    mozilla-central ———————————
    \ \ \ / \ /
    tracemonkey —————————- (end of project tree)

    Of course, actually showing this on your pretty diagram might be more confusing than useful.

  2. Nit picking a little more… “mozilla-1.8” is really “mozilla-1.8.1” even though the branch is still listed as MOZILLA_1_8_BRANCH. (Hence the Gecko version string of 1.8.1.19, for example.)

    Also, “cvs trunk” is that, but it’s also the 1.9.0 branch, just not a “branch” in the |cvs tag -b -r| sense.

  3. hi bsmedberg;

    Whether a branch has:
    – one-way merges from mozilla-central (like the new mozilla-1.9.1, or like cvs-head)
    – two-way merges from mozilla-central and merges back to mozilla-central (like tracemonkey)
    …seems to be more a characteristic of the role of that branch to the human developers, regardless of whether the underlying SCM implements it as an actual branch or a clone.

    And yes, you are correct – no matter how many ways I tried, showing any of those dotted lines of merges going back and forth quick turned this 2″ by 2″ diagram into a completely unreadable mess. 🙁

    tc
    John.

  4. Minor nit: IIRC Mozilla 1.8.0 branched off Mozilla 1.8, and not the other way around. We started off with a single 1.8 branch (MOZILLA_1_8_BRANCH) and then created 1.8.0 (MOZILLA_1_8_0_BRANCH) to continue the 1.5.0.x series when 2.0 development needed to continue.