I read [1]. IMO, it is discussing a different topic. In fact, the previous chapter [3] is about release branches and talks about making fixes in the release branch.
My takeaway is that [1] is about deciding what changes that have occurred in the develop branch since the last release should go into the release branch when it is time to create the release branch. IMO, this is not currently a problem for Flex. We should just take everything. I suppose someday something in the develop branch could be so risky that we have second thoughts, but I’d say we shouldn't discuss what to do until we have an actual scenario. -Alex On 12/2/14, 5:59 AM, "e...@ixsoftware.nl" <e...@ixsoftware.nl> wrote: >Hi, > >Fred brought up an interesting point in the other thread: should fixes >during the release phase be made on 'develop' and then merged into >'release', or the other way around? > >This article [1] talks about deciding which features to include in a >release, and it leans towards merging from 'develop' to 'release'. >Which, for new features, makes sense. On the other hand, there is this >article [2] talks about fixes, which it suggests should be made on >'release' and merged into 'develop' right away. > >As the RM for this release I tend to lean towards NOT adding features >to the 'release' branch after it has been cut, and to commit bug fixes >to the 'release' branch. > >Thoughts? > >EdB > >1: http://producingoss.com/en/stabilizing-a-release.html >2: http://nvie.com/posts/a-successful-git-branching-model/ [3] http://producingoss.com/en/release-branches.html
