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

[Guilhem Bonnefille <guilhem.bonnefille@c-s.fr>]

Hi all,

Far from internal development of Orekit, I fear to be off-topic, but
playing with Git from long time now, I wish to share some of my thoughs
with you.


Le 31/07/2017 à 11:30, MAISONOBE Luc a écrit :
> 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.
>
> He suggested using git-flow
> (<http://nvie.com/posts/a-successful-git-branching-model/>,
> <https://www.atlassian.com/git/tutorials/comparing-workflows>,
> <https://github.com/petervanderdoes/gitflow-avh/wiki>,
> <https://danielkummer.github.io/git-flow-cheatsheet/>).
>
> The third and fourth link above even propose a few extensions to help
> using
> git flow. The third link seems to be the one installed on Debian systems.
>
> What this branching model would imply is that there would be a develop
> branch
> that is evolving rapidly and the master branch would be more stable as it
> will change only when releases are made.

Git-flow is a great workflow. But it has a major drawback when used in
*industrial* context: it does not offer the ability to fix a (really)
old stable version. In git flow, every new release should be merged on
master before publication. But, when you plan to support old stable
branches, you will be faced to the situations where the 8.0 version
needs a patch (8.0.1) while the 9.0 is already published.

As this is part of your requirements, I suggest you to document a
strategy for this situation. As suggested before, one good point is to
follow the semantic versionning. Doing this, we can imagine the
following extension to gitflow:
* major and minor (X.Y or X.Y.0) versions are merged to master
* patch version (X.Y.Z) are living in their own branches, named
X.Y-patch (for example) and tagged on this branch

We can easily imagine that reporting such bugfixes will not work with a
git merge because code bases can be really different, so perhaps should
we directly recommend to use git cherry-pick.

> External users that want to get the latest released version would
> therefore
> be able to retrieve it directly from git, using the master branch.
> External
> users that want the latest bleeding-edge version with finished features
> would retrieve the develop branch.

IMHO, external users should not be interested in using the branches
develop of feature-*. If so, we can imagine that the real problem is the
lack of intermediate public versions.

Integrating gitflow will offer the ability to release much more often.
And, as orekit has a lot of good practices around tests and quality,
gitflow is certainly the last piece of organisation allowing frequent
releases for quite nul effort.
With gitflow, the branch develop is quite stable. Furthermore, any huge
refactoring breaking API can be developped in a dedicated (long living)
feature branch. So, the releasing process become quite simple, we gain
lot of confidence on the effective quality of the release content and
finally we can release often.

> People wanting to set up nightly builds (someone asked for it a few
> months
> ago on these lists) could use either the master or the develop branch, or
> even both branches in separate builds, depending on their needs.
>
> Orekit team developers ready to work and contribute on unfinished
> features
> would use feature branches, some internal to their private repository in
> their work machine, some pushed to the public repository at orekit.org
> for
> collaborative work.

Yes, regularly building master and develop branch can increase the
confidence on the product.
On project using the "pull-request" scenario on GitHub, we observe that
build jobs are fired on this event. This simplify the work of the
integrator: before looking at the contribution, he already know the
status of this contribution (mergeable or not, break the build or not...).
Building any published feature-branch can certainly help its future
integration into develop.

> What do you think?
>

It is a great idea to improve this part of the Orekit management process.

Best regards.

begin:vcard
fn:Guilhem Bonnefille
n:Bonnefille;Guilhem
org;quoted-printable:CS Syst=C3=A8mes d'Information;Division Espace
adr:;;Parc de la Grande Plaine - 5, rue Brindejonc des Moulinais - BP 15872;Toulouse Cedex 05;;31506;France
email;internet:guilhem.bonnefille@c-s.fr
title:Architecte
tel;work:05 61 17 62 84
url:http://www.c-s.fr/
version:2.1
end:vcard