On Friday 04 November 2011 15:11:40 you wrote: > On Friday 04 November 2011 15:05:18 Alberto Villa wrote: > > Last case I can think of: *.1 revision. You tag 0.x.y from master, and > > then merge feature A to it. But people starts screaming that 0.x.y > > removes root partition. So you checkout tag 0.x.y (all these tasks are > > *instant* > in > > > Git), branch off from it, delete the "rm -rf /*` hidden in Kdenlive > > configuration wizard, and tag 0.x.y.1 from the branch. To complete the > > operation, you merge the branch into master (and solve potential > > conflicts, should the `rm -rf /*` have been changed to `sudo rm -rf /*` > > in > > > master). > > Oh, and you then merge master to next. ;)
Hi Alberto and all! Thanks for the explanations! I now have read your mail 3 times and I think I understood! So if I put it in other words, it would work like this: * If I want to fix a simple thing: - I work on it on my local copy of master and commit it directly to master, then it is also merged to 'next'. * If I want to work on something more complicated, ex. rewrite effect stack: - I create a remote 'feature' branch from master - I work on it and commit my changes to the branch, other people can also help - When it is ready for testing, I merge my branch into 'next' - Bug fixes go in my 'feature' branch and are merged again in 'next' for testing - When it is stable, my 'feature' branch is merged into 'master', 'master' is merged into 'next' and my remote 'feature' branch is deleted. * Of course one can also work on a local branch of master for some reasons... Now, I have 2 questions / comments: 1) What about string freeze? My proposal to wait a few weeks before merging new features after a release was to make sure that no new string is introduced if we make a .1 release. But then it would block development, so I think that if we need to make a .1 release, it is probably better to do as you proposed: create a new branch from the release tag, fix the problems in this branch, create new release from that branch then merge changes to master. 2) Are some of the merges automated? I mean that if I fix a stupid bug in 'master', will it automatically be merged to 'next' or do I have to do it manually? We shoud probably set up a web page to list the commands for the most common operations (create a branch, merge it to next, how to update your branch with latest changes from master or next, ...) Regards jb
