Changes between Version 8 and Version 9 of StartModMaint
- Timestamp:
- Dec 9, 2013, 2:43:54 PM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
StartModMaint
v8 v9 8 8 Library maintenance occurs in the context of how Boost repositories are organized. Please study the [wiki:ModBigPicture Modular Boost Overview] before continuing, since a Boost developer needs to be familiar with how Boost organizes its repositories. 9 9 10 The examples given on this page follow Boost recommended workflow practices, but avoid discussion of workflow rationale to keep this introductory level page simple. If you feel you need to understand workflowrationale before continuing, feel free to read [wiki:StartModWorkflow Modular Boost Library Workflow Overview].10 The examples given on this page follow Boost recommended workflow practices, but keep workflow discussion simple for this introduction. If you feel you need to better understand workflow recommendations and rationale before continuing, feel free to read [wiki:StartModWorkflow Modular Boost Library Workflow Overview]. 11 11 12 12 == Prerequisites == … … 18 18 * {{{b2}}} in your path. That allows most of the command line examples given here to work as shown on both Windows and POSIX-like systems. 19 19 20 == Checking out the branch == 20 == Getting started == 21 22 === Checking out the branch === 21 23 22 24 {{{ … … 40 42 }}} 41 43 42 == Verify Tests Working==44 === Verify Tests Working === 43 45 44 46 Before making any changes to you library, which we will call {{{mylib}}}, be sure the test suite is working in the modular Boost environment: … … 49 51 }}} 50 52 51 == Fix a simple bug == 53 == Typical maintenance tasks == 54 55 === Fix a simple bug === 52 56 53 57 These commands could be used for any Git project, modular or not, so hopefully you are already somewhat familiar with them: … … 61 65 }}} 62 66 63 == Start work on a new feature == 67 === Fix a complex bug === 68 69 === Start work on a new feature === 64 70 65 71 Simple bugs are usually fixed on the {{{develop}}} branch, at least in smaller projects. There is usually no need to first create a bug-fix branch. But git developers usually create a (possibly private) branch to work on new features, since development of new features on the development branch might leave it unstable for longer that expected. … … 68 74 ... to be supplied ... 69 75 }}} 76 77 === Merge a completed feature branch to {{{develop}}} === 78 79 === Do a simple release === 80 81 === Do a major release === 70 82 71 83 == Merging to Master for the First Time ==
