flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Date Thu, 09 Aug 2012 16:09:33 GMT

On 8/9/12 12:00 AM, "Omar Gonzalez" <omarg.developer@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.

View raw message