Since I'm one of the "author" of the current 1.0 branch, I'd like to join the discussion and make sure whether I get it right.
It looks like the the proposed approach is to replace cherry-pick by creating a feature branch and merge that branch into branches we'd like to have the fix. If we're going this approach, then the feature branch should be derived from the targeted back port branch. For example, if patch A is getting in both branch-1.0 and master, then we should create a feature branch from 1.0 name branch-A, and add patch A on top of branch-A, and then merge branch-A into branch-1.0 and master, respectively. Basically, the above is what I concluded from your discussion. Is this the same as what you're thinking? 2015-07-15 22:34 GMT+08:00 Olaf Flebbe <[email protected]>: > Cos, > > > Evidently, "is not mutable" and "shouldn't be moved" are two very > different > > properties. > > Of course, you are right. > > > What github does for their releases is of no relevance to us,. > > You are right, but I would like to mention we use this in bigtop.mk, too. > > HUE_SITE=https://github.com/cloudera/hue/archive > DATAFU_SITE=https://github.com/linkedin/datafu/archive > TACHYON_SITE=https://github.com/amplab/tachyon/archive > > I would pledge for putting an tag release-1.0.0 on the release commit . > Like we did before. > > >> I doubt you can move a tag once it is pushed to the apache repository > (since > >> a force push is not possible, too), but we may try ;-) > > > > Tag is a pointer to a git object. The pointer could be deleted, > recreated and > > pushed again: no force-push is needed for that. > > That is evidently not true: > > $ git tag -d olaf > Deleted tag 'olaf' (was 6fd647e) > $ git tag olaf HEAD~3 > $ git push lr --tags > ... > ! [rejected] olaf -> olaf (already exists) > error: failed to push some refs to '.....' > > > > Besides, force-push isn't disabled on Apache repos (except for master > branch). > > > Yes, we can do whatever we want with the branches. > > > Didn't know that. Now I am beginning to understand your point ... > > I wrote an example workflow (see attachement) . I would propose to add > this example (if it is correct) to the developer guidelines in the wiki. > > Management summary: We should be careful not to apply changes affecting > both release and master directly to one of these branches. Use a fix branch > instead and merge it to both master and release branch. > > Using github pull request seems equivalent to this workflow, btw. > > Thanks all for your patience, over and out. > Olaf > > > > > > > >
