This page describes the process of creating stdcxx release branches, and merging changes between them.
- Each release branch reflects the minor version of the library and contains changes for all micro releases 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 letterx
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. trunk
corresponds to the next major version in development. When it comes time to start the release process for 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 version 5.0.0,branches/5.0.x
will be created off oftrunk
. At that point,trunk
becomes the future 6.0.0.- 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
and4.3.x
, andtrunk
, changes that are both backward and forward compatible are first made onbranches/4.2.x
and then merged tobranches/4.3.x
and then totrunk
. Changes that are forward but not backward binary compatible are first made onbranches/4.3.x
and then merged totrunk
. Incompatible changes are made only ontrunk
. - 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.
- 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. - 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 entry.