9. Git Branching Model on Git now (see Note 2) +1 (binding)
-----Original Message----- From: Daniel Harfleet [mailto:dharfl...@yahoo.com] Sent: Wednesday, August 15, 2012 4:31 AM To: flex-dev@incubator.apache.org Subject: Re: [VOTE] Branching Strategy and SCM 9. Git Branching Model on Git now (see Note 2) +1 (non-binding) ________________________________ From: Alex Harui <aha...@adobe.com> To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org> Sent: Monday, 13 August 2012, 21:19 Subject: [VOTE] Branching Strategy and SCM Hi, It is time to make a decision on branching and source control vendors. This vote will end at 2pm PDT Wednesday, August 15. Please vote for one of the following. 1. 3-Tier Branching Model (see Description 1) on SVN 2. 3-Tier Branching Model on SVN now and then on Git (see Note 1) 3. 3-Tier Branching Model on Git now (see Note 2) 4. Classic Model (see Description 2) on SVN 5. Classic Model on SVN now and then on Git (see Note 1) 6. Classic Model on Git now (see Note 2) 7. Git Branching Model (see Description 3) on SVN 8. Git Branching Model on SVN now and then on Git (see Note 1) 9. Git Branching Model on Git now (see Note 2) Note 1: The switch to Git will occur when Apache Infra approves Git as an official SCM option (and after any release that might be in-progress at that time. Note 2: Requires finding volunteers to work with Apache Infra and Apache Infra and Apache Incubator PMC approval. If Apache does not approve, votes will be automatically re-cast for "SVN now and then on Git". Description 1: 3-Tier Branching Model In this model, there is a "trunk" branch that is almost always production-ready, a "develop" branch, and various other branches on whiteboards and elsewhere on an as-needed basis. - Bug-fixes and low-risk features can be implemented directly in "develop". - Long-term and/or risky work is committed to branches and whiteboards. A release manager will send an email describing which commits will be promoted to trunk in order to create a release. This is because not everything in the "develop" branch will be ready to go in the next release. Folks can offer up other commits or discourage promotion of some commits based on technical reasons. It is up to the release manager to decide which commits get promoted and the release manager will perform the commits to trunk or request assistance from others to make the commits. Release candidates are generated from trunk. Bugs found in the RC are fixed in trunk and merged back to develop. When the release is approved, the trunk is tagged. If a hotfix is required a branch, the issues are fixed directly in trunk unless the hotfix is for an older release, in which case a branch is made from the tag, issues are resolved in the hotfix branch, and the hotfix branch is re-integrated to trunk and then to develop. Description 2: Classic Model This model is the classic SVN model. Changes are made in trunk, branches are made when needed. To create a release, a branch is made of trunk. The release manager will decide whether to branch from an older revision and cherry-pick certain revisions or branch from head and remove/block certain revisions. Bugs found in the RC are fixed in the release branch. When the release is approved, the branch is tagged and re-integrated into trunk. If a hotfix is required, a branch is made from the tag. Description 3: Git Branching Model This model is described here: http://nvie.com/posts/a-successful-git-branching-model/ The "master" is what is currently "trunk". We will make a new branch from trunk called "develop". The release manager can choose to branch from an older revision and cherry-pick or branch from the head and remove/block certain revisions. My Summary of Differences Between Models: Git Branching Model keeps trunk always production-ready, 3-Tier keeps it mostly production ready, Classic means that trunk is "bleeding-edge". Git Branching Model requires branches in certain situations. 3-Tier and Classic require good developer judgment on when to make branches. There will probably be fewer branches in 3-Tier and Classic. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
