On Wed, Sep 10, 2014 at 7:50 PM, Philip Bennefall <phi...@blastbay.com> wrote:
> Hi all, > > I have a question about how to properly use branches in the following > scenario: > > I have version 1.0 of my software, which is stable. Then I want to start > developing version 2. Initially I make a version2 branch where all > development happens, while at the same time I continue to maintain trunk > which is currently version 1. > This is what we do on SQLite: (1) We try to keep the trunk always working. (This helps when doing bisect in later years.) New development goes on feature branches until (a) we know it is going to be merged into a release, and (b) it passes all tests. Then it gets merged into trunk. A recent example of a feature branch is "btree-speedup" (http://www.sqlite.org/src/timeline?r=btree-speedup). Or changes can be made directly on trunk as long as they pass all tests and do not seem risky or disruptive. As I write this, we are working on three separate feature branchs: user-auth, 64-bit-lengths, and experimental-bulk-update. (2) Release is from trunk. We just --tag a trunk check-in with "release" and with "version-X.Y.Z". We also set --bgcolor 'xd0c0ff' so that releases have a distinct background color. (3) New development after the release continues to go onto trunk (once it passes tests as required by [1] above). If we need to patch a release, then the patches go into a branch rooted at the release. The branch for version-X.Y.Z is named "branch-X.Y.Z". Example: http://www.sqlite.org/src/timeline?r=branch-3.8.4 (4) We also maintain a few long-term branches in parallel with trunk. These are versions of SQLite that we have no immediate plans to merge into trunk but need to track trunk. The current long-term branches are "apple-osx" (containing the slightly-modified code that gets shipped with MacOS and iOS) and "sessions". Up unto just recently, we were also maintaining the "threads" branch, but it has now been merged into trunk. Sometimes we will make a check-in to trunk then later decide it doesn't belong there, so then move it into a branch. (You can do that easily in Fossil.) An example is the "btree-speedup" changes which started on trunk but got move to a branch. See the timeline at http://www.sqlite.org/src/timeline?c=2014-08-20 and specifically the edit at 13:11 for when the original trunk check-in was moved into the "btree-speedup" branch. -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
