[IPython-dev] (slightly OT) tags vs. branches

[Aaron Meurer]

So I guess it depends on how many branches you can handle at once, and
how distributed your development model is.  For example, do people
commit new stuff directly to a branch in the official repo, like is
being done with the htmlnotebook with IPython, or do they work on it
in branches their individual branches and merge with master of the
official repo when it's all ready?  The ease of branching and the
highly distributed nature of git lets you develop in any one of
probably hundreds of different paradigms, so it really depends on how
your community is laid out and what your development procedures look
like (and don't be afraid to change these, too, especially if you are
coming from a centralized background with something like svn).  For
example, in SymPy, we require all code to be reviewed (even from
developers with commit access), so our process inevitably looks a
little different from IPython's.

I think you'll find that with GitHub, a highly distributed system
works very well, because people can just submit pull requests to each
other (that's right, to each other, not just to the official repo),
and merge the work together very easily.

Going back to the original question, though, I do highly recommend
tagging the exact commit you do a release with, as this is a pretty
standard practice.  The rest will vary from project to project.

Aaron Meurer

On Tue, Aug 16, 2011 at 9:22 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Tue, Aug 16, 2011 at 8:14 PM, Aaron Meurer <asmeurer at gmail.com> wrote:
>> I can't speak for IPython, but this is how we use them with SymPy.
>>
>> As you know, the HEAD commit of a branch moves as the branch is
>> updated, whereas a tag always points to the same commit.  Therefore,
>> you should always tag the commit that is used to make a release, so
>> that people can recreate it exactly from the tag if they want to.
>>
>> With SymPy, when we get ready to release, we create a new branch with
>> the name of the version (like 0.7.1), and prepare the release there.
>> This lets development continue in master, even though that may be less
>> stable than you would want preparing for a release.  Once the release
>> is done, I tag the commit, and merge the release branch back into
>> master (btw, it's important to merge, not rebase).  Generally, at this
>> point, we delete the release branch, as it's useless and redundant,
>> but I suppose this may not always happen.
>>
>> Aaron Meurer
>>
>> On Tue, Aug 16, 2011 at 9:05 PM, David Warde-Farley
>> <wardefar at iro.umontreal.ca> wrote:
>>> Gentlemen,
>>>
>>> I noticed you have both tags and branches related to releases. As I am currently in the midst of getting the Theano team up to speed on git (woohoo! we've switched!) and the GitHub pull request style of workflow (via gitwash and my various tl;dr cribbings from it), I wonder if you could enlighten me on why you have both, and what each might be useful for.
>
> And, for us nipy-ers - we tag the release something like 1.1.0, then
> form a maintenance branch 1.1.x for fixes to that series, in case we
> want to release 1.1.1, etc, while we're developing what will be 1.2.0.
>
> See you,
>
> Matthew
>