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

[Alex Afanasyev]

On Jul 16, 2014, at 4:21 PM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:

> On Thu, Jul 17, 2014 at 1:03 AM, Alex Afanasyev
> <alexander.afanasyev at ucla.edu> wrote:
>> 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).
> 
> Are you talking about remote (i.e. server-side) feature branches?

If needed, either can be used.  But only if really needed.

>> 
>> Also, as I understand the flow, the release-* branches are temporary and
>> they go away as soon as the release is finalized and tagged.
>> 
> 
> Yes, or you can keep them in order to make hotfix releases if needed,
> in which case the "release" branch would be unnecessary. I don't have
> a strong opinion either way.
> 
>> 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.
> 
> Remember to merge back to master after tagging.
> 
>> 
>> - we will have "release" branch that will track the latest release (release
>> = latest release tag)
>> 
> 
> Yes or, as I said, keep the various release-N branches. But probably a
> single branch generates less noise and less confusion...?
> 
> Another question is: what is the default branch that gets checked out
> when cloning? master or release?

This will remain "master" (where most development happens).

>> - 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
>> 
> 
> Just call it "release-X.1", "release-X.2", etc... less confusion in my opinion.

I already create release-0.2.0 this time.  Next time we could remove the last zero.

---
Alex

>> - 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
>> 
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev