Difference between revisions of "Source branches"
Rob Linden (talk | contribs) |
Rob Linden (talk | contribs) (updated to reflect the fact that Branch_1-17-0 is the branch with the current released viewer) |
||
| Line 5: | Line 5: | ||
There are generally four major branches at all times, along with many temporary development branches: | There are generally four major branches at all times, along with many temporary development branches: | ||
* '''Numbered branch (currently "Branch_1- | * '''Numbered branch (currently "Branch_1-17-0")''' - this is where the current release resides, and where very minor fixes get checked in for the next minor release (e.g., if 1.15.0.2 is the last release, then changes for 1.15.0.3 would get checked in here). | ||
* '''"release"''' - the main trunk of development. This is often referred to as "head" or "trunk" in other organizations. Linden Lab is rather conservative about what gets checked into release, though, preferring that development work mainly happens on branches (either a dedicated feature branch, or "maintenance" for the small stuff, and only gets merged into release once QA has happened. We aspire to keep release compatible with the agni (main) grid. All branches occasionally pick up changes from release, and are occassionally merged back into release. | * '''"release"''' - the main trunk of development. This is often referred to as "head" or "trunk" in other organizations. Linden Lab is rather conservative about what gets checked into release, though, preferring that development work mainly happens on branches (either a dedicated feature branch, or "maintenance" for the small stuff, and only gets merged into release once QA has happened. We aspire to keep release compatible with the agni (main) grid. All branches occasionally pick up changes from release, and are occassionally merged back into release. | ||
* '''"release-candidate"''' - when Linden Lab is working toward a major release, this branch provides a similar function to release, but is for changes that are compatible with the beta grid (usually aditi) rather than the release grid | * '''"release-candidate"''' - when Linden Lab is working toward a major release, this branch provides a similar function to release, but is for changes that are compatible with the beta grid (usually aditi) rather than the release grid | ||
Revision as of 21:37, 13 June 2007
The public version control repository provided by Linden Lab has many of the same branches that Linden Lab's internal repository has.
There are generally four major branches at all times, along with many temporary development branches:
- Numbered branch (currently "Branch_1-17-0") - this is where the current release resides, and where very minor fixes get checked in for the next minor release (e.g., if 1.15.0.2 is the last release, then changes for 1.15.0.3 would get checked in here).
- "release" - the main trunk of development. This is often referred to as "head" or "trunk" in other organizations. Linden Lab is rather conservative about what gets checked into release, though, preferring that development work mainly happens on branches (either a dedicated feature branch, or "maintenance" for the small stuff, and only gets merged into release once QA has happened. We aspire to keep release compatible with the agni (main) grid. All branches occasionally pick up changes from release, and are occassionally merged back into release.
- "release-candidate" - when Linden Lab is working toward a major release, this branch provides a similar function to release, but is for changes that are compatible with the beta grid (usually aditi) rather than the release grid
- "maintenance" - bug fixes and small features that don't warrant their own branch get checked into maintenance. Changes from maintenance are periodically merged up to release and release-candidate after QA has tested a build from the branch. Many source code contributions from the community land in this branch first.
Other branches are typically branched from release or release candidate.
Linden Lab does feature development on temporary branches. As those features mature, they are merged into the "release-candidate" branch. The QA group tests the feature, and often, the feature is deployed on the beta grid for public testing. QA will then either reject or approve it for inclusion in "release". When a major release is about to happen, a branch is created for work on that release (e.g. "Branch_1-13-2"), which gets synced with the "release" branch periodically. Then, stability work is done on the branch, and the new code is deployed. After that, any stability work gets merged back into "release", and the process repeats for the next major release. In the meantime, stability work continues on the branch for maintenance releases.