stdcxx-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Stdcxx Wiki] Update of "Branching" by MartinSebor
Date Sat, 28 Jun 2008 21:42:33 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Stdcxx Wiki" for change notification.

The following page has been changed by MartinSebor:

The comment on the change is:
Described process for branching and merging.

New page:
This page describes the process of creating stdcxx release branches, and merging changes between

 1. Each release branch reflects the minor version of the library and contains changes for
all micro release for that minor version. The name of the branch is {{{branches/<major>.<minor>.x}}}
where `<major>` and `<minor>` and the major and minor version numbers, respectively.
for the release. The letter `x` denotes all micro versions. For example, [
branches/4.2.x] is a branch for all of 4.2.0, 4.2.1, 4.2.2, and so on. Similarly, [
branches/4.3.x] is a branch for all of 4.3.0, 4.3.1, etc.
 1. `trunk` corresponds to the next major version in development. When it comes time to start
the release process of the next major version, a new branch for the version is created. The
name of the branch follows the naming convention listed above. For example, when it comes
time to release 5.0.0, `branches/5.0.x` will be created off of `trunk`. At that point, `trunk`
becomes the future 6.0.0.
 1. Changes are first committed to the branch for the lowest appropriate version number and
then merged upward. Specifically, given the two branches, 4.2.x and 4.3.x, and trunk, changes
that are both backward and forward compatible changes are made on `branches/4.2.x` and then
merged to `branches/4.3.x` and then to `trunk`. Changes that are forward but not backward
binary compatible are made on `branches/4.3.x` and then merged to `trunk`. Incompatible changes
are made on `trunk`.
 1. Merges between branches are done often, no less frequently than once a month, to minimize
the tedium involved and the risk of introducing mistakes or missing important changes.
 1. The Change``Log for each merge must mention the revision numbers of all changes merged
and contain the corresponding Change``Log entry for each. An example of a such a Change``Log
entry is this [ commit].
 1. When merging a change that itself resulted from a merge from another branch, only the
original revision number and Change``Log entry should be mentioned in the new Change``Log

View raw message