stdcxx-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Stdcxx Wiki] Update of "Branching" by MartinSebor
Date Mon, 30 Jun 2008 15:29:13 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:
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.

Mime
View raw message