> > > A thought: why not follow guidelines for version control and NOT merge > > changes from develop into an RC branch? > Because: > - Changes were made in develop that were needed in the release branch > - Only the release branch is tested so for a RC to be tested it must be in > sync with develop > - Given infrequent releases we need all the fixes :-) > - Cherry picking is too much trouble and causes all sort of other issues > (eg merging with trunk) >
- If those changes were essential to a stable release, they should've been made in the RC branch, to be merged into develop after release, not the other way around. - That's by your choice, I've offered repeatedly to create RC test suites during a release cycle. - One of the reasons the releases are 'infrequent' is because they are a lot of work. A bit of structure and developer discipline during the release process will reduce that work load considerably, IMHO. - When the only changes checked into the RC branch are fixes made to that branch - because of issues reported specific to the branch, reported AFTER the branch is cut - there shouldn't be more than a handful of 'm per RC. Also, I believe an second RC should be just another tag on the original RC branch, not a new branch of develop - too many changes will have been made on develop while the RC process is ongoing. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
