Changes between Version 3 and Version 4 of ModBigPicture


Ignore:
Timestamp:
Dec 3, 2013, 3:28:58 PM (9 years ago)
Author:
Beman Dawes
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • ModBigPicture

    v3 v4  
    88Modular 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
    10 All public repositories are hosted at [https://github.com/boostorg GitHub].
     10All public repositories are hosted at [https://github.com/boostorg GitHub] {{{boostorg}}}.
    1111
    1212Releases of individual libraries occur asynchronously from releases of the Boost super-project.
    … …  
    1414== Repositories ==
    1515
    16  * 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.
     16 * The Boost super-project has its own [https://github.com/boostorg/boost public repository] within {{{boostorg}}}. It treats each individual library as a submodule, 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 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.
     18 * Each individual library has its own public repository within {{{boostorg}}}. 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
    2020 * 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.