incubator-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: Discuss: Branching Strategy and SCM
Date Tue, 14 Aug 2012 05:36:28 GMT
>
> 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.

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

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