> > 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
