Build lab

(Redirected from Labs)

A build lab (or simply a lab) commonly refers to a Microsoft Windows source code branch. By extension, it can also refer to the team that works on this branch.

Historically, the build lab was a physical room populated with machines that periodically produced mainline builds of Windows NT. At first, there was a single build lab for the entire project that all developers submitted their changes to. As the number of developers grew, the concept of virtual build labs was introduced, where each team developing a subset of the feature set works on its own separate branch and has one or more machines compiling periodic builds of that branch. Each developer first submits their changes to their team's branch, and are merged to the mainline development branch only after meeting a required subset of acceptance criteria. Other teams can then pull the changes from the mainline branch into their development branches.

Builds that were not built by the build lab machines, but are rather compiled by individual Microsoft employees, are called private builds. They are identified by having the VS_FF_PRIVATEBUILD file flag set in the executable's version information and by including the account name of the individual or service that initiated the build in the branch part of the build tag.[a][b]

Labs[edit | edit source]

Microsoft has used several branching systems since the start of Windows XP development, which differ in the hierarchy of labs as well as in the naming scheme. However, there are some specifics common to most schemes, such as the presence of a top-most main branch, or the use of special branches for important development milestones.

Whistler and pre-reset Longhorn[edit | edit source]

The top-most branch was called main, which integrated changes from all labs. Under it were several numbered labs, each of which was working on a separate part of Windows, such as:

  • Lab01: Kernel
  • Lab02: Networking
  • Lab03: Server[c]
  • Lab04: Terminal Services[1]
  • Lab06: User interface
  • Lab07: Internet Information Services/COM+

These labs also had a "_N" branch, which served as a buffer between main and the actual branch. For example, changes from the main branch would first get integrated into Lab06_N before later being integrated into Lab06 in a process called forward integration. The same applied for reverse integration, where the lab would first integrate changes into its N-branch before integrating them into the main branch.

There were also idx (internal development workstation/server) branches, builds from which are usually recompilations intended for TAP/OEM partners. However, they were also occasionally released for public testing, e.g. Windows Longhorn build 4074 or Windows XP build 2257.

Before the release of Windows XP, the main branch was forked into the xpclient branch while the main branch moved on to track Windows Server 2003 development. After the final version was shipped, new branches were created for updates, hotfixes and Service Pack development. Similarly, the dnsrv branch (short for Dot NET Server, i.e. Windows .NET Server) was forked from the main branch before the release of Windows Server 2003.

Since Longhorn reset[edit | edit source]

The lab hierarchy was overhauled after the development reset of Longhorn to address the flaws that plagued most of the pre-reset period. Instead of having a small amount of general virtual build labs each focusing on a different general scope of Windows functionality, a new hierarchial model with considerably more feature branches was introduced, which helped reduce the amount of code to reverse integrate for branch. Microsoft also set stricter criteria for reverse integrating changes from the labs into the main branch, which was now renamed to winmain.

The main branch was later renamed to rsmain at some point after the release of Windows 10, and then to rsmaster after the Windows source repository's conversion to Git, likely to comply with the Git convention of calling the top-most branch the master branch. At some point after February 2021,[2] the branch was renamed back to main. This was likely done in order to follow suit with other Microsoft projects after the master/slave terminology became a subject of controversy in 2020 due to slavery connotations.[3][4]

Feature branch prefixes[edit | edit source]

Microsoft has used multiple prefixes to refer to feature branches over time:

Windows 10 November Update and Windows 10 Anniversary Update used their respective release branch prefix for feature branches - th2 and rs1, respectively.

Release branch prefixes[edit | edit source]

Similarly to the previous system, the main branch is forked off before release to contain update development. The following is the list of known prefixes:

Branch prefixes used by other teams[edit | edit source]

Some teams that use the Windows codebase but are formally separate from Windows releases also use their own branch prefixes:

See also[edit | edit source]

Notes[edit | edit source]

  1. ↑ For example, build 6.0.4067.private/lddm_dev_tech(davidmo).040212-1646 is a private build initiated by the davidmo user.
  2. ↑ Some builds such as 6.0.4002.Lab06_N(ntvbl06).030108-1926 and 6.1.6469.fbl_find_dev(wexbuild).071002-1531 are compiled as private builds but were built by an official build lab machine account.
  3. ↑ This lab still compiled client builds even though it worked on server components as the build process does not distinguish between client and server SKUs.
  4. ↑ fs branches were used in parallel with rs branches.

References[edit | edit source]

  1. ↑ Chen, Raymond. The importance of having a review panel of twelve-year-old boys, episode 2, The Old New Thing. 11 April 2013.
  2. ↑ Windows 10 build 21298 (rsmaster)
  3. ↑ Brown, Shelby. Microsoft's GitHub is removing coding terms like "master" and "slave", CNET. 27 July 2020.
  4. ↑ Regarding Git and Branch Naming, Software Freedom Conservancy. 23 June 2020.

External links[edit | edit source]

Retrieved from "https://betawiki.net/index.php?title=Build_lab&oldid=329309"