On 8/13/12 10:36 PM, "Omar Gonzalez" <omarg.develo...@gmail.com> wrote:
>>
>> Also the vote added this to the above options - "The release manager can
>> choose to branch from an older revision and cherry-pick or branch from the
>> head and remove/block certain revisions." Which I have concerns about as
>> it's not quite how I saw the process as described in the URL.
>>
>> Thanks,
>> Justin
>
>
> That's because that's not how its supposed to work in the GBM.
>
> "The release manager can choose to branch from an older revision and
> cherry-pick or branch from the head and remove/block certain revisions."
>
> This is never mentioned in GBM.
That's correct. I added it on purpose, because I don't see how folks will
be able to decide what goes in Flex.Next as there is no product schedule,
and with volunteers, you never know when you think you have time and be
wrong. This is different from dedicated development where you know at
release planning time who is working on stuff due for the current release
and who, if anybody, is on a longer term project.
If we take the conservative approach of following GBM as written and do not
check stuff into the develop branch until you are absolutely sure it is
ready to go, then you will have delayed sharing or made it harder as we have
to keep switching to different branches in order to try others work.
I would love to believe that we can fully verify something that is in a
branch before it gets checked in, but I just don't think it will happen.
Folks will need to have their work get some scenario testing and checking in
stuff into "develop" that doesn't break anything but may not be complete is
to me the easiest option. I believe we will get more done by taking time to
cherry pick at release time rather than trying to manage all of these
feature branches and then find they need more baking when finally merged
into "develop" and put under real world use.
>
> In the GBM strategy the dev branch is basically Flex.Next always. The
> master/trunk is always the last stable release to be cut. As features are
> finished they are added to Flex.Next (dev).
>
> If you complete a feature and you aren't sure it should go into Flex.Next
> yet then you leave the feature in its Feature Branch until you deem it
> ready for Flex.Next.
>
> In this way you have an easy way of keeping features in a place where they
> can be worked on yet aren't polluting the Flex.Next (dev) branch with
> incomplete or broken features.
>
> Whenever Flex.Next has enough feature branches merged in that we feel its
> time for a release then that's when a Release Branch is made and everything
> can be updated/fixed that needs to be when prepping a new release. This is
> the branch where Release Candidates would come from. Once its ready to be
> released you tag it and merge it back to Dev, and to trunk. Merging to
> trunk should trigger an automated build for the release product.
>
> So at no point would you be trying to cherry pick features out of a branch
> to put into a release. They should already be organized in feature branches
> so they're marked as ready for integration when the feature is complete and
> discussed/tested by the Flex comm.
>
> While I don't think that the process would be nearly as smooth on SVN I do
> believe the concepts could apply in SVN, its just hard for me to say how
> efficient/inefficient it would be because I've never tried that model in
> SVN.
>
> -omar
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
