Changes between Version 1 and Version 2 of ModBigPicture


Ignore:
Timestamp:
Oct 27, 2013, 2:00:59 PM (9 years ago)
Author:
Beman Dawes
Comment:

First draft

Legend:

Unmodified
Added
Removed
Modified

  • ModBigPicture

    v1 v2  
    66== Overall Organization ==
    77
    8 Modular Boost consists of the Boost super-project and separate projects for each individual library in Boost. In terms of Git, the Boost super-project treats the individual libraries as sub-modules.
     8Modular Boost consists of the Boost super-project and separate projects for each individual library in Boost. In terms of Git, the Boost super-project treats the individual libraries as [http://git-scm.com/book/en/Git-Tools-Submodules sub-modules].
    99
    1010All public repositories are hosted at [https://github.com/boostorg GitHub].
    … …  
    1616 * The Boost super-project has its own [https://github.com/boostorg/boost public repository]. It treats each individual library as a sub-module, i.e. a link to a particular release in the library's public GitHub repository. The super-project is maintained by the Boost release managers, and most library developers do not have write access.
    1717
    18  * Each individual library has its own public repository. For example, Boost.Config has a [https://github.com/boostorg/config public repository]. The maintainer of a library decides who has write access to the public repository. Release managers and their helpers also have write access for administrative purposes.
     18 * Each individual library has its own public repository. For example, Boost.Config has a [https://github.com/boostorg/config public repository here]. The maintainer of a library decides who has write access to the public repository. Release managers and their helpers also have write access for administrative purposes.
    1919
    20  * As with any Git repository, a library's developers do day-to-day work using private repositories on their local machines. When they push changes from these local private repositories up to the library's public repository is up to them, as is when the library issues releases. As usual with Git, the local repositories may have private branches that are never pushed to the public repository.
     20 * As with any Git project, a library's developers do day-to-day work using private repositories on their local machines. When they push changes from these local private repositories up to the library's public repository is up to them, as is when the library issues releases. As usual with Git, the local repositories may have private branches that are never pushed to the public repository.
    2121
    2222 * Libraries are required to follow certain naming conventions for branches and directories, so that both humans and automatic test and management tools know where to find commonly referenced components. But beyond those requirements, each library is free to use whatever branch and directory strategies they wish.
    … …  
    2424== Branches ==
    2525
    26 To
     26Releases for both the super-project and individual libraries are always on a branch named "master". Branch master should be stable at all times. Branch master should only be pushed to the library's public repository when it is ready to ship.
    2727
    28  * that has a "develop" branch for development work, and a "master" branch for your releases, which occur asynchronously from Boost releases. You may also have other branches, but that's up to you.
    29  * You (and the rest of your team)
    30  * Your library's directory structure conforms to [http://www.boost.org/development/requirements.html#Directory_structure Boost directory structure conventions], so both users and automatic processes can find header files, test files, build configurations, and the like. Beyond the conventions, your library's directory structure is up to you.
     28Boost strongly encourages that the main development branch be named "develop".
    3129 
    3230== Directory Structure ==
    3331
    34 For Modular Boost, header files are placed in a {{{include/boost}}} header hierarchy within your main directory. Here is what a very simple header-only library named {{{simple}}} would look like:
     32Your library's directory structure conforms to [http://www.boost.org/development/requirements.html#Directory_structure Boost directory structure conventions], so both users and automatic processes can find header files, test files, build configurations, and the like. Beyond the conventions, your library's directory structure is up to you.
     33
     34For Modular Boost, header files are placed in a {{{include/boost}}} directory hierarchy within the library's top-level directory. Here is what a very simple header-only library named {{{simple}}} would look like:
    3535
    3636{{{
    … …  
    4646}}}
    4747
    48 In other words, the directory structure of a library in {{{boost-root/libs}}} for modular Boost is the same as pre-modular Boost, except that it contains another sub-directory hierarchy, {{{include/boost/...}}}, where {{{...}}} represents the library's directories and header files that previously lived in {{{boost-root/boost}}}. The effect of this change in directory structure is that the library is now entirely self-contained in a single directory and its sub-directories.
     48In other words, the directory structure of a library in the library's top level directory for modular Boost is the same as pre-modular Boost, except that it contains another sub-directory hierarchy, {{{include/boost/...}}}, where {{{...}}} represents the library's directories and header files that previously lived in {{{boost-root/boost}}}. The effect of this change in directory structure is that the library is now entirely self-contained in the top-level directory.
    4949
    5050A real library would also have additional sub-directories such as {{{doc}}}, {{{example}}}, and {{{src}}}, as described in the [http://www.boost.org/development/requirements.html#Directory_structure directory conventions], but they are left out of {{{simple}}} for the sake of brevity.
     51
     52== Git Flow for Workflow ==
     53
     54Boost recommends, but does not require, the approach to library workflow that has come to be known as [http://nvie.com/posts/a-successful-git-branching-model/ Git Flow]. For more about how this applies to Boost libraries, see [wiki:StartModWorkflow Getting Started with Modular Boost Library Workflow].
     55
    5156