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 omarg.developer@gmail.com
 designates 74.125.82.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20120105192800.492BB816020@nike.apache.org>
References: <20120105192800.492BB816020@nike.apache.org>
Date: Thu, 5 Jan 2012 11:33:37 -0800
Message-ID: 
 <CAEFz_vsprEsQJzTK_hHDD=WPpAtj69Z97biS36AZ78knkwqOCQ@mail.gmail.com>
Subject: Re: Branch Strategy (was: So, what should we do first?)
From: Omar Gonzalez <omarg.developer@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016e6d7ec2c4549b504b5cd021a

--0016e6d7ec2c4549b504b5cd021a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 5, 2012 at 11:26 AM, Rui Silva <flex@rduartes.net> wrote:

> Alex,
>
> I think BRANCHES would do just fine for all branching needs (not TRUNK and
> TAGS).
>

Right, so for example to be more clear in how I was envisioning what we're
discussing:

Here are some tags:
-tags
  -releases
    -v.1.0
    -v.1.1

I notice there's a bug reported for v.1.0, and it still exists in 1.1. So I
branch from 1.1 to fix it, it is JIRA2819. So I make a branch:
-branches
  -sandboxes
    -s9tpepper
      -v.1.1.fixForJIRA2819

I start the name with v.1.1 so I can quickly tell which tag this branch
came from, and give it a descriptive suffix to know what the purpose of
this branch is. When my work here is done I can submit this as a patch, and
that patch can then be reviewed, and if passes, we can then determine which
release it will fall into which will determine where it gets merged back
into production.

Nothing under the tags folder should ever be changed, there is only 1
commit to these 'branches'.

Is this what you're envisioning too Rui?

-omar

--0016e6d7ec2c4549b504b5cd021a--