On 8/9/12 12:00 AM, "Omar Gonzalez" <omarg.develo...@gmail.com> wrote:

>> 
>> 
>>> My ultimate first choice would be to get this project on Git. :)
>> Maybe I'm missing something, but my read of the article was that the
>> "develop" branch was the same as "unstable" and is even more restrictive
>> about checkins to trunk than I was thinking.  It just seems to want to use
>> even more branching. How does that make things better?
>> 
>> 
> The "develop" branch is where things get integrated and stabilized. The
> "develop" branch also always has all of the latest fixes that are ready to
> be integrated into the next release.
> 
> When its time for a release you make a "release" branch to make the changes
> to the source required for a new version, update version number, etc.
> 
> While this "release" is being prepared development can continue in parallel
> for the next stuff.
Why is this better than just pulling selected changes?  No need to lock down
if you know which changes you are going to take.
> 
> This would happen by going to the "develop" branch and making a new
> "feature" branch. New stuff starts getting developed here.
I think our whiteboards can be feature branches, but again, why is it
required to use branches for everything?
> 
> Now the release can be prepared while new features and fixes are being
> developed as well.
> 
> When the "release" branch is ready to actually be released, version numbers
> updated etc, the release branch is tagged "v.1.1". Then the release branch
> is merged to "develop" to get it up to date w/ the release changes. Then
> the release branch is merged to "trunk/master" which triggers a Jenkins
> build and a new version of the product.
> 
> When the "feature" branch is stable, it is ready for the next release, so
> it is merged back into the "develop" branch and stabilized. When all the
> "feature" branches have been merged back to "develop" and its ready for a
> new release you rinse and repeat the whole process.
> 
> This approach works because it allows parallel development, off of
> baselines that are always easily found, because they're branched from
> either "develop" if its a new upcoming feature, or branched from a version
> tag if its a "hotfix" to an existing version.
> 
> 
> -omar
Will svn tagging work as well or was this description for Git?

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Reply via email to