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