22 | | == Getting started == |
23 | | |
24 | | The preferred development environment is usually for the library being worked on have a development branch checked out, while other Boost libraries are as pointed to by the Boost super-project {{{master}}} branch. This causes local tests of your library to run against {{{master}}} for other Boost libraries as last accepted by the Boost super-project. |
25 | | That is a more realistic test environment in than testing against the possibly unstable {{{develop}}} branch of other Boost libraries or against the {{{master}}} branch of other libraries as of a different point in time than that seen by the super-project. Robert Ramey has advocated this approach to testing for years, and Git and the modularization of Boost via submodules makes this approach easier. |
| 22 | == Typical maintenance tasks == |
| 23 | |
| 24 | === Getting ready to work on a library === |
| 25 | |
| 26 | The preferred environment for working on a library is to have {{{develop}}} or some other development branch checked out, while other Boost libraries are as defined by the Boost super-project {{{master}}} branch. This causes local tests of your library to run against {{{master}}} for other Boost libraries as last accepted by the Boost super-project. |
| 27 | Thid is a more realistic test environment in than testing against the possibly unstable {{{develop}}} branch of other Boost libraries or against the {{{master}}} branch of other libraries as of a different point in time than that seen by the super-project. Robert Ramey has advocated this approach to testing for years, and Git and the modularization of Boost via submodules makes this approach easier. |