flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <omarg.develo...@gmail.com>
Subject Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Date Thu, 09 Aug 2012 07:00:03 GMT
> > 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.

This would happen by going to the "develop" branch and making a new
"feature" branch. New stuff starts getting developed here.

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message