A lab or a VBL (virtual build lab) commonly refers to a team working on a part of the Windows operating system, or the source code branch that the team works on. Originally, a build lab was a room with machines periodically producing official builds of Windows NT. Initially, there was a single build lab for the entire project, however, as the number of developers grew, teams working on different parts of the operating system were assigned their own virtual build labs, which included a branch of the project code, as well as the infrastructure to build the code. This carried over to Source Depot branch names, which led to the term being also used for the teams themselves and the branches. The branch name forms a part of the build tag, a unique identifier of a Windows compile.
Builds that were not built by the build lab machines 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 person or service who initiated the build in the branch part of the build tag.[note 1]
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 (sometimes called the "trunk") 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:[note 2]
- Lab01: Kernel
- Lab02: Networking
- Lab03: Server[note 3]
- Lab04: Terminal Services
- 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 main 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 main.
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 trunk 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 was forked from the trunk 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 hierarchic model with considerably more feature branches has been 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 trunk, which was now renamed to winmain.
The trunk 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. The trunk branch was renamed at some point after February 2021 back to simply
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 alleged slavery connotations.
Feature branch prefix[edit | edit source]
Microsoft has used multiple prefixes to refer to feature branches over time:
- vbl (virtual build lab) - Windows Vista
- fbl (feature branch level) - Windows 7 up to Windows 10 (original release)
- rs (Redstone) - Windows 10 Creators Update up to now
- fs (Firesteel) - Windows 11 (version 21H2)[note 4]
Release branch prefix[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:
- vista, longhorn, lh - Windows Vista, Windows Server 2008
- win7 - Windows 7, Windows Server 2008 R2
- win8 - Windows 8, Windows Server 2012
- winblue - Windows 8.1, Windows Server 2012 R2
- th1 - Windows 10 (original release)
- th2 - Windows 10 November Update
- rs1 - Windows 10 Anniversary Update, Windows Server 2016
- rs2 - Windows 10 Creators Update
- rs3 - Windows 10 Fall Creators Update
- rs4 - Windows 10 April 2018 Update
- rs5 - Windows 10 October 2018 Update, Windows Server 2019
- 19h1 - Windows 10 May 2019 Update, Windows 10 November 2019 Update
- vb (Vibranium) - Windows 10 May 2020 Update, Windows 10 October 2020 Update, Windows 10 May 2021 Update, Windows 10 November 2021 Update
- mn (Manganese)
- fe (Iron) - Windows Server 2022
- co (Cobalt) - Windows 11
- ni (Nickel) - Windows 11, version 22H2
Notes[edit | edit source]
- For example, build
6.0.4067.private/lddm_dev_tech(davidmo).040212-1646is a private build initiated by the
- Originally, the
ntvblprefix was used for labs, although it was later changed to
Labin the beginning of the development of Windows XP.
- 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.
fsbranches were used in parallel with