[Nfd-dev] Small branching policy change for NFD and ndn-cxx (proposal)

[Alex Afanasyev]

My understanding is slightly different, but in any case it aligns with your concern about the feature branches.  I don't think that the described git flow requires you to use feature branches for everything.  It allows you to do this, but doesn't mandate (I have used it a few times before).  Given that we also have code review system in place, it in most cases replaces this process ( "feature branch" is basically a series of patch sets).

Also, as I understand the flow, the release-* branches are temporary and they go away as soon as the release is finalized and tagged.

So, the short list of proposed updates:

- we will create "release-<version>" branch for preparation for <version> release.  When the release is finalized, we tag the release and remove the branch.

- we will have "release" branch that will track the latest release (release = latest release tag)

- for problems discovered for the released <version>, we can use "hotfix-<version>+" branch, which is merged back to "master" and "release" branches, and then tagged as then next minor release

- feature branches can be used (if a complex feature needs to be separated in multiple inter-dependent commits before merged to master), but they mostly replaced by the code review process.

---
Alex

On Jul 16, 2014, at 3:10 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Dear folks
> 
> As I understand, the git flow model + change of master role results in the following:
> 
> * releases are tagged, and also have branches with prefix "release-"
> * features need feature branches
> * feature branches are merged into master branch, which reflects latest developments
> 
> This differs from current practice in that:
> 
> * release branches add "release-" prefix
> * feature branches are used
> 
> I agree with adding a "release-" prefix to release branches.
> 
> I disagree with using feature branches, because merging conflicts would be a problem.
> Every Change should still target to master branch.
> 
> Yours, Junxiao
> 
> On Jul 17, 2014 5:01 AM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:
> Hi guys,
> 
> I have a proposal to slightly modify the current policy for branching in our repos to partially match the git flow model described http://nvie.com/posts/a-successful-git-branching-model/.
> 
> The part I'm not entirely agreeing with is the role that devoted to master branch in this model: it always points to the latest release.  Personally, 'master' branch for me is the place for development, while there could be other "release" branch to track latest releases.   The rest of the workflow generally follows what we have been doing in the past, just formalized operations a little.
> 
> If agreed, I will create "release-0.2.0" branch in both repos that will fix all the features for the upcoming release.  All pending/approved commits on gerrit then can be merged into master, which will track further development.
> 
> Any objections?
> 
> ---
> Alex
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140716/0eceea39/attachment.html>