incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Dalton <bendal...@gmail.com>
Subject Re: [VOTE] Branching Strategy and SCM
Date Mon, 13 Aug 2012 20:26:02 GMT
#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
> 
> 



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message