| |
Version Control with Subversion - Common Use-Cases - Release Branches
Release Branches
Most software has a typical lifecycle: code, test,
release, repeat. There are two problems with this process.
First, developers need to keep writing new features while
quality-assurance teams take time to test supposedly-stable
versions of the software. New work cannot halt while the
software is tested. Second, the team almost always needs to
support older, released versions of software; if a bug is
discovered in the latest code, it most likely exists in
released versions as well, and customers will want to get
that bugfix without having to wait for a major new
release.
Here's where version control can help. The typical
procedure looks like this:
-
Developers commit all new work to the
trunk.
Day-to-day changes are committed to
/trunk: new features, bugfixes, and
so on.
-
The trunk is copied to a
“release” branch.
When the team thinks the software is ready for release
(say, a 1.0 release), then /trunk
might be copied to
/branches/1.0.
-
Teams continue to work in parallel.
One team begins rigorous testing of the release branch,
while another team continues new work (say, for version
2.0) on /trunk. If bugs are
discovered in either location, fixes are ported back and
forth as necessary. At some point, however, even that
process stops. The branch is “frozen” for
final testing right before a release.
-
The branch is tagged and released.
When testing is complete,
/branches/1.0 is copied to
/tags/1.0.0 as a reference
snapshot. The tag is packaged and released to
customers.
-
The branch is maintained over time.
While work continues on /trunk for
version 2.0, bugfixes continue to be ported from
/trunk to
/branches/1.0. When enough
bugfixes have accumulated, management may decide to do a
1.0.1 release: /branches/1.0 is
copied to /tags/1.0.1, and the tag
is packaged and released.
This entire process repeats as the software matures:
when the 2.0 work is complete, a new 2.0 release branch is
created, tested, tagged, and eventually released. After
some years, the repository ends up with a number of release
branches in “maintenance” mode, and a number
of tags representing final shipped versions.
[an error occurred while processing this directive]
|
|
