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
workflow.sh
Description: Binary data
signature.asc
Description: Message signed with OpenPGP using GPGMail
