Re: [Orekit Developers] Using git-flow branching model?

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

"Ward, Evan" <Evan.Ward@nrl.navy.mil> a écrit :

> Hi Luc, All,

Hi Evan,

> On Mon, 2017-07-31 at 11:30 +0200, MAISONOBE Luc wrote:
>
> Hi all,
>
> For some times now, some experienced developer (Sébastien), has urged me to
> adopt a better branching model for Orekit. Doing everything in master,
> except for a few branches from time to time, is not really good.
>
> What do you think?
>
>
>
>
> I would be fine with trying out a new git strategy. I don't have  
> much experience with the different strategies being discussed, but  
> as long as the chosen strategy is documented well I should be able  
> to make my git history look like whatever you all choose. I tend to  
> prefer a linear history (using `git merge --rebase`) but the other  
> folks on this thread have made some good points in favor of having a  
> branchy history. Is there a concern with having a large number of  
> branches in a single repository or deleting old branches?

There should not be really a problem with lot of branches, it is just
an inconvenience for users running "git branches -a". So I would say
we should delete feature branches once merged, and the "git merge --no-ff"
helps for traceability in this case).

So I think we agree. I will set up a "develop" branch for next version,
with the pom set up to "9.1-SNAPSHOT" as the pom already needs to know
this version during development, to avoid confusion with released branches.

I will also revert the pom setting in master branch to the last release
status, and from now on we should *not* commit to master directly,
but should only merge official release branches there.

I will set up a skeleton documentation about this. At first, it will be
really basic (I am on holidays right now, so should not work much).

best regards,
Luc

> Best Regards,
> Evan