Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of flexcapacitor@gmail.com
 designates 209.85.161.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMFKFRivpeCwDVywQK+0S7wnh1Nb-H67ocmJhb2g1FaF-jKj8w@mail.gmail.com>
References: <CC4EAF57.446B9%aharui@adobe.com>
 <CAMFKFRivpeCwDVywQK+0S7wnh1Nb-H67ocmJhb2g1FaF-jKj8w@mail.gmail.com>
From: jude <flexcapacitor@gmail.com>
Date: Tue, 14 Aug 2012 06:41:11 -0500
Message-ID: 
 <CANcBHECVZ17RF0EpebyRdPQTpKP3sO=w2qjvrz0jmG9ftCJgRQ@mail.gmail.com>
Subject: Re: [VOTE] Branching Strategy and SCM
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae9341251a65f8804c7384a4a

--14dae9341251a65f8804c7384a4a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

9 (unbound)

Jude

On Mon, Aug 13, 2012 at 3:25 PM, Carlos Rovira <
carlos.rovira@codeoscopic.com> wrote:

> My non-binding vote goes without doubt for GIT with nvie model:
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> So 8 --> Git Branching Model on SVN now and then on Git
>
> Thanks
>
> Carlos
>
>
> 2012/8/13 Alex Harui <aharui@adobe.com>
>
> > 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 Apach=
e
> > 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 commit=
s
> > 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 t=
o
> > 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, branch=
es
> > are made when needed.
> > To create a release, a branch is made of trunk.  The release manager wi=
ll
> > 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 hotf=
ix
> > 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 i=
t
> > mostly production ready, Classic means that trunk is "bleeding-edge".
> > Git Branching Model requires branches in certain situations.  3-Tier an=
d
> > Classic require good developer judgment on when to make branches.  Ther=
e
> > will probably be fewer branches in 3-Tier and Classic.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
>
>
> --
> Carlos Rovira
> Director de Tecnolog=EDa
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> <http://www.codeoscopic.com>
> CODEOSCOPIC S.A. <http://www.codeoscopic.com>
> Avd. del General Per=F3n, 32
> Planta 10, Puertas P-Q
> 28020 Madrid
>

--14dae9341251a65f8804c7384a4a--