Hi Folks, We are about to switch to a branchy, topic-based workflow for CMake development with Git. The approach is based on a workflow documented in "git help workflows". We've written a Wiki page to document it:
http://public.kitware.com/Wiki/Git/Workflow/Topic along with step-by-step development instructions. Please read this carefully before doing any development after the transition to the new workflow. Here is the transition plan: (1) Disable pushes to "cmake.git". We need to freeze to complete the transition cleanly. (2) Merge my 'version' branch into master. This introduces a new version numbering scheme to handle the new workflow. Basically, master is "major.minor.patch" for releases and then "major.minor.patch.<date>" during development beyond a release. For example, 2.8.1.20100504 predates release 2.8.2, and development after 2.8.2 is something like 2.8.2.20100601. This way the version on master always increases. Also, an abbreviated Git commit hash will be appended to development versions (e.g. 2.8.1.20100504-g2f944). (3) Merge the 'release' branch into master. This represents the end of separately staged release branches. The merge will be done as follows: (3a) Merge but keep everything from master (git merge -s ours) (3b) Amend merge to revert version from 2.9.0 back to 2.8.1 (3c) Amend merge to add ChangeLog.manual (3d) Amend merge to add changes since 2.8 started to ChangeLog Despite the "amend" steps, this is not a so-called "evil merge". It is a logical merging of the 2.9 and 2.8 development paths. (4) Spawn maint from 'v2.8.1'. (5) Spawn next from 'master'. These are the new integration branches. See the above workflow documentation. (6) Switch 'nightly' to follow 'next' by robot (7) Switch 'release' to follow 'master' by robot These are branches to be followed by dashboard clients. The current "Nightly" and "Nightly Expected" sections of the dashboard will follow 'nightly'. The current "Nightly 2.8 Release" section will follow 'release'. No CTest dashboard scripts need to change if they already follow one of these branches. (8) Enable pushes to cmake.git on 'next'. Core developers will merge release-ready topics to master. This replaces our previous mass cherry-pick&squash pattern for preparing release candidates. -Brad _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
