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: http://wiki.apache.org/stdcxx/Branching The comment on the change is: Fixed typos. ------------------------------------------------------------------------------ This page describes the process of creating stdcxx release branches, and merging changes between them. - 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, [http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/ branches/4.2.x] is a branch for all of 4.2.0, 4.2.1, 4.2.2, and so on. Similarly, [http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/ branches/4.3.x] is a branch for all of 4.3.0, 4.3.1, etc. + 1. 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 letter `x` denotes all micro versions. For example, [http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/ branches/4.2.x] is a branch for all of 4.2.0, 4.2.1, 4.2.2, and so on. Similarly, [http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/ 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. `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 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. 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 are first 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 first made on `branches/4.3.x` and then merged to `trunk`. Incompatible changes are made only 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 [http://svn.apache.org/viewvc?view=rev&revision=664184 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 entry.
