#9 for sure (if my vote counted)
On Monday, August 13, 2012 at 4:19 PM, Alex Harui wrote: > 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 > >
