[CCC DEV] Branch question/confusion

[Matt Jadud]

Hi Martin,

OK. Sounds mostly reasonable. I'm going to suggest a change or two, since
we have so few active developers.

1. Do work in own forks/branches.
2. Pull requests for review.

I doubt we can hold anyone accountable for anything, but it is a good
thought.

In terms of branching and releasing: back-merging anything sounds like
work. Unless we can justify the time, how about if we just tag at stable
points. Declare major revision updates when a big feature comes in.
Otherwise, let the past in the repos be the past? (Or, if you prefer, give
me a good reason why the back porting matters? I don't see one, but I'll
admit that I haven't thought about it.)

Cheers,
Matt


On Wed, Apr 24, 2013 at 8:09 AM, Martin Ellis <ellism88 at gmail.com> wrote:

> What I was suggesting was.
>
> All work is done in our own forks/branches.
> We make a pull request and someone else in the team must review and pull
> it into master when we are happy with it.  This way we get code review, and
> these two people become responsible if something breaks.
>
> Branching and tagging for release is separate.
> We make a 1.6 branch off of master, this is not committed to directly, all
> new work goes into master, we just cherry-pick bug fixes from master.
> If we want a new feature, or master and 1.6 diverge so far that we can no
> longer cherry-pick bug fixes we make a new branch from master and bump the
> 6.
> Tags signify releases on a branch.  They should be done at stable points.
> 1.6.0 is the first stable point on the 1.6 branch.
> We make new tags after pulling in fixes from master and when we think it
> is stable.
> We Tag often...?
>
> does this sound sensible?
>
>
>
> On Wed, Apr 24, 2013 at 12:37 PM, Matt Jadud <matt at jadud.com> wrote:
>
>> Hi all,
>>
>> I'm unclear about the branch tagging question.
>>
>> Should we:
>>
>> 1. Tag at known good points, and
>> 2. Do all development in trunk?
>>
>> or
>>
>> 1. Tag as we start work, and
>> 2. Do development in a branch?
>>
>> With git, it seems like the natural workflow is:
>>
>> 1. Tag releases/feature points
>> 2. Fork to explore/fix.
>> 3. Request merges to bring them into trunk.
>> 4. Branch for extended explorations
>>
>> I'm sure there's a workflow description out there for using git
>> efficiently. I guess I'm just wondering /confused by the recent branching
>> conversation---why would we do all our work in a branch, and then... merge
>> back to trunk, as opposed to doing our work, and tagging at a point that we
>> might want people to do a checkout?
>>
>> Or, did I confuse things horribly? I spent a good chunk of time with a
>> screaming baby last night, so do please excuse the confusion.
>>
>> Cheers,
>> Matt
>>
>> _______________________________________________
>> developers mailing list
>> developers at concurrency.cc
>> http://lists.concurrency.cc/mailman/listinfo/developers
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.concurrency.cc/pipermail/developers/attachments/20130424/0c9d9f57/attachment.htm>