[CCC DEV] Branch question/confusion

Fred Barnes F.R.M.Barnes at kent.ac.uk
Wed Apr 24 13:47:46 BST 2013


Hi,

Martin writes:
> 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.

As Matt identifies, doing work in our own forks branches then making pull requests
requires that someone (other than the committer) gets involved.  In many cases
that's extra effort.  On a large project, with lots of main and side-line developers,
I can see how that makes sense.  But for kroc I'd go for something like:

 - commits straight to master for small/own changes (e.g. fixes/updates/etc.).
 - in a branch if changing chunks of others' code, or widespread changes that
   may have knock-on effects in other builds, and pull-request in so people get
   a chance to look (but for mainstream developers, I wouldn't see self-pulling
   as a problem).
 - in a fork for external bodies and pull requests for changes coming in from
   outside (e.g. someone developing a new module for something or other, or
   supporting another TVM arch, etc.).

> 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.

Yep.  Again, I wouldn't object to developers cherry-picking their own fixes/updates
into the stable branch (otherwise we're likely to generate backlog).


> 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.

I'd save 1.6 -> 1.7 type moves for big changes, and 1.6.0 -> 1.6.1 for lesser
things, like new modules, new features (if at all).


> 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...?

I'd save tagging for when 1.6.0, 1.6.1, ... become available.  When telling
people to get the stable kroc, they'll be downloading the kroc-1.6 branch,
rather than a particular tag, so should get all the fixes-to-date.


Cheers,

-- Fred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
URL: <http://lists.concurrency.cc/pipermail/developers/attachments/20130424/06c66afb/attachment.pgp>


More information about the developers mailing list