[CCC DEV] Branch question/confusion
matt at jadud.com
Wed Apr 24 13:27:17 BST 2013
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
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.)
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
> 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?
>> 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.
>> developers mailing list
>> developers at concurrency.cc
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the developers