Git - branch or tag?

Question

I have a API that was developed using python 2.7. I have some developers that are already using it. I would like to migrate this API to python 3.4. I will not give support for the python 2.7 API anymore.

My code is stored in bit bucket. What is the best strategy? Just make a simple branch, e.g., "python3.4"?

Make a tag on the master branch (python 2.7) and start a new branch (python 3.4)?

Answer 1

Yes, branching is correct. It is possible that you will want to fix a bug in the Python 2 branch, so it should be a branch, and not a tag. Tags are for releases.

I would name the Python 2 branch python2 and name the Python 3 branch master. This way, it is more obvious which branch is active.

Answer 2

Perhaps, as far as the users are concerned, you don't actually have to do anything other than announcing that support for the 2.7 API has ended with the most recent release (which already has a tag). No immediate git action is required.

(If you want to give the users something newer which still supports 2.7, then that calls for one more "last 2.7-based release" before the cut-over.)

A more recent tag denoting the actual commit before the cut-over would be useful for your internal purposes, though. Cutting over to the new API is a significant change, which perhaps deserves to be marked by a tag so you can easily refer to this historic point.

You don't have to make any support branch now. Doing so could signal to users that you intend to support the API, which you don't. ("Oh goodie, I see a python2 branch; that's where I can expect fixes, in spite of the announcement that there won't be any!") It's easy to later create the branch based on a suitable tag, if you change your mind.

That branch could be made from the point before the cut-over, or farther back from the last official release supporting the 2.7 API: there is no need to decide the exact branch point now if you have no intent to support the API at all.

If you later create the branch based on a tag, git won't automatically set up tracking (that is to say, you can't do git branch -t). But in this situation you don't need that anyway, because you won't be rebasing the python2 support branch, only cherry-picking fixes into it.