Re: Reference for git.git release process

Raman Gupta [off-list ref] writes:

One question about the dev process:

1) I don't see any topic branches available in git.git. Are these
generally kept in a private repo and/or shared between individual
developer's public repositories?

I do not answer "generally" part, but in git.git, I do not publish heads
of individual topic branches.  I could, but simply I don't, because that
has been the way I've operated so far, and I am too lazy to change my
configuration.  Also I suspect it would make my life more cumbersome
because I have to prune stale topics from the public repositories from
time to time.

Some questions about the release process:

1) After a release is made (master is tagged with vX.Y.Z), is the
maint branch deleted and recreated from the new release tag? e.g.

git branch -d maint
git branch maint master

It is rather:

        git checkout maint
        git merge master

which should be the same because the merge should fast-forward, but an
advantage is that it would keep the reflog of 'maint'.

In addition, you can keep older maintenance track around, i.e.

	git branch maint-X.Y.(Z-1) maint
        git checkout maint
        git merge master

so that maintenance releases for even older codebase _could_ be issued
_if_ necessary.

2) MaintNotes states:

"After a feature release is made from "master", however, "next" will
be rebuilt from the tip of "master" using the surviving topics"

Does this mean:

git branch -d next
git checkout -b next master
git merge ai/topic1_to_cook_in_next
git merge ai/topic2_to_cook_in_next

That is more-or-less correct, even though I'd actually do either

	git branch -f next master

or

	git checkout next
        git reset --hard master

instead of deleting and recreating.