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 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CC4818CC.442AE%aharui@adobe.com>
References: 
 <EB6F7A48D477254EAB8F675582F80CD7267CFEE4@DPSBS1.digitalprimates.local>
	<CC4818CC.442AE%aharui@adobe.com>
Date: Wed, 8 Aug 2012 18:42:16 -0700
Message-ID: 
 <CAEFz_vspajYGsO5Yy9yoBzDjTudpq9fB6d3=X=o51xnd2cpDnw@mail.gmail.com>
Subject: Re: SVN and issues with branching / consider how we use SVN going
 forward
From: Omar Gonzalez <omarg.developer@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d043894ad5f190804c6cb56fb

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

>
>
> The author of the article seemed to want to make a release branch so that
> whatever hits the trunk is essentially a snapshot of a release.  I'm not
> quite sure that is worth it if at the point there is a group of us
> dedicated
> to making a release and fixing things that are broken.


The point of the release branches are to prepare what is in the dev/trunk
branch for release. That would include changing the build number, updating
a change log, fixing docs, those types of minor changes that come with
making a release. Even very minor bug changes can be done in a release
branch. Once its ready to be shipped you push to dev/trunk which should
trigger a Jenkins build which produces a new version of the product. If you
continually make the small changes in dev/trunk then your continuously
making new versions of the product, so the idea of the release branch is
just to make those small changes and get it ready to 'go out the door'.
Once it goes out the door you tag it and that's the EOL for the release
branch.

-omar

--f46d043894ad5f190804c6cb56fb--