Hi! > Main problem is that our current workflow doesn't allow branch-only > changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only > you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go > there.
Why would you want a bugfix to be in 5.3 but not in 5.4? Can you give an example? I can see it if the code had substantial change there so bugfix no longer applies. In this case, I would try the merge, see it fail and resolve it as "all ours". It shouldn't take longer than 10 mins. Though it you have ideas how to improve that without disrupting the rest of the process and the common use case, you are welcome. > 1) use cherry-picking in one repo. This has big downside (as dsp > pointed) that we can't use git annotate, bisect and other commands > assuming that commit is introduced in repository only once. bisect is a bit weird now btw, since it seems to be a bit confused by 5.3-5.4 merge that happened not when it thinks it did - so if you try to bisect changes in 5.4 branch only, you will get some very old changes in. You can quickly go through that, marking them as good, but still not ideal situation. > Okay, since I'm not too familiar with release process, assume > following (please, correct me if I'm wrong): > * PHP 5.3 can't have features, only bugfixes True. > * PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and > master) and bugfixes that should stay only in PHP-5.3 Not entirely true - 5.3 code can have bugfixes that aren't merged up, but that would not be the common case. Example - bugfix regarding magic quotes or safe mode, which are not in 5.4. > * PHP-5.4 and master can have bugfixes and features that are merged > upstream (master) and bugfixes/features that should stay only in > current branch 5.4-only fixes very unlikely, as master and 5.4 are very close today. If we ever do big changes in master this is a possibility, as described above, but still won't be a common case - unless we rewrite our engine completely, which doesn't seem to be likely. > * All branches are have regular releases True, except for master. > In gitflow you have 4 branches: > * master - contains only production ready releases, nobody commits here > directly > * develop - main development branch, all work usually is get merged here > * feature/<name> - feature/bugfix branches for separate bugfixes and > features. Merged into develop. > * hotfix/<name> - same that feature branches but is urgent and is > always merged into master *and* develop. For example, when security > release is issued, this fix should go into release and into main > development branch. > * release/<name> - pre-release stability branches, for bug-fixes only. > Merged into develop and master (making a new release). When you have a > release branch, you can't commit into develop (so hotfixes go here > too, if we have release branch). I don't like that "can't commit into" thing - the main advantage of git as I see it that you can manage release branch and dev/stable branches separately and not have the situation of asking people to sit on their code for 2 months while release is being stabilized. > Make a bugfix in 5.3 > $ git flow feature start bugfix PHP-5.3 # create a bugfix branch based on 5.3 > $ git flow feature finish -k bugfix 5.3-develop > Bugfix get merged into 5.3-develop - this should be implemented since > gitflow supports only 1 develop branch for now. -k says to keep branch > after finish, since we'll need it to merge upstream Why would we need bugfix branch in our repo here? I would say keep it in your own fork, test it, show it off, get it ready - then merge it into php repo. What is the reason for us to keep halfbaked fix branches in our repo? > Merge bugfix from 5.3 repo to 5.4 > First, rebase branch against 5.4 > $ git rebase --onto develop-5.4 bugfix~<num> bugfix > Where <num> is number of commits in your branch. I know it sucks, but > that's how it works :) I don't like it. Too fragile and too easy to mess up. In general, this scheme seems quite complex and I don't really see what the benefit of it would be. Could you explain why would we want to do this? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
