| | 1 | = Proposed Git Workflow = |
| | 2 | |
| | 3 | == Goals == |
| | 4 | |
| | 5 | 1. Improve stability of both the server and client software. |
| | 6 | 2. Lay the foundation for feature branches should we ever decide to use them. |
| | 7 | |
| | 8 | == Branches == |
| | 9 | |
| | 10 | dev = server development |
| | 11 | master = server stable |
| | 12 | dev_client = client development |
| | 13 | master_client = client stable |
| | 14 | |
| | 15 | == Initial state after migration == |
| | 16 | |
| | 17 | master forked to dev |
| | 18 | master forked to dev_client |
| | 19 | |
| | 20 | dev_client forked to master_client |
| | 21 | |
| | 22 | == Client Development == |
| | 23 | |
| | 24 | Bug fixes and new simple features start out in dev_client and are merged to master_client when needed. |
| | 25 | |
| | 26 | (if feature branches are used) fork dev_client to client_XXX where XXX is the feature name. Do work in client_XXX until complete. Merge completed feature into dev_client. |
| | 27 | |
| | 28 | === Release Process === |
| | 29 | |
| | 30 | Dev builds (odd minor version) are built out of the dev_client branch. Tags are created when the build number is incremented. |
| | 31 | |
| | 32 | master_client is forked to boinc_client_release_X_XX when a new dev_client release is considered stable. Any future bug fixes for the X_XX release are handled in its branch. |
| | 33 | |
| | 34 | Mass merge of outstading commits from dev_client to master_client. Increment minor version number. |
| | 35 | |
| | 36 | == Current Unknowns == |
| | 37 | |
| | 38 | Can git merge a 'lib' change from dev to dev_client? How about the other way? |
