incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <p...@adobe.com>
Subject Re: [VOTE] Branching Strategy and SCM
Date Mon, 13 Aug 2012 21:32:10 GMT
#9 for me. This seems more fluid and adaptable to unforeseen situations
where multiple concurrent branches may be needed, some short-term, some
quite long-term. Plus, having a known release branch should make it easier
for newcomers to understand and for anyone to immediately know where the
stable versions are located.

I don't really care too much if it is git or svn, but if there is a move
to git, might as well be sooner than later.

--peter


On 8/13/12 4:19 PM, "Alex Harui" <aharui@adobe.com> 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
View raw message