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

[Davide Pesavento]

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?

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

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

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