Git Workflow

[Dominik Charousset]

Wen I started using Git, I looked around for best practices and found this guide: http://nvie.com/posts/a-successful-git-branching-model/

The gist of it is to use topic (or feature) branches for developing new features, an integration branch for merging new features once they’re ready but not fully tested yet and hotfix branches for bugs that must get fixed as quickly as possible.

I think overall this is a solid model that works well. There’s one quirk, however. The guide (and thus CAF) never pushes to `master` except for releases. The integration branch is `develop`. This makes `master` essentially superfluous for us since it’s simply the state of the top most release under the release tab on GitHub.

The `master`-is-production-ready philosophy makes sense for company-internal libraries that don’t have regular releases. For CAF, however, I feel like it’s just a quirk at this point and doesn’t work well with GitHub issues and PRs. It’s also confusing potential contributors.

Long story short, I think it’s time to drop the `develop` branch and get rid of the `fixed in develop` label for good. Any objections or comments?

    Dominik

[Matthias Vallentin]

This sounds like a reasonable simplification of the development process to me. For users who want a specific version of CAF, they can always check out a specific tag or download a release tarball with the source. Those who checkout master, in my eyes, should get the development snapshot.

FWIW, we had the exact line of reasoning when we defined the git workflow for the Bro project several years back. The full guidelines are here: https://www.bro.org/development/howtos/process.html#id1

Matthias

[Sebastian Woelke]

I like the idea.

Another benefit: On the first glance CAF would look more active.
As I think it looks suspicious, when the last master commit is months
old.

Sebastian

[Marian Triebe]

If our current branching is already too confusing for potential contributors, what would they think about the c++11 template „magic“?
I don’t see that we would get more contributors if we switch the branching model.
I also don’t like the idea of having some sort of rolling release on master branch.
If we push unstable content to master, which will happen, this would not make a good impression.

Marian

> --
> You received this message because you are subscribed to the Google Groups "caf-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to caf-devel+...@googlegroups.com.
> To post to this group, send email to caf-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/caf-devel/ecd0009670904c06f9eca13cc65b99a3%40posteo.de.
> For more options, visit https://groups.google.com/d/optout.

[Dominik Charousset]

If our current branching is already too confusing for potential contributors, what would they think about the c++11 template „magic“?

I don’t think these things are related. :)

I don’t see that we would get more contributors if we switch the branching model.
I also don’t like the idea of having some sort of rolling release on master branch.
If we push unstable content to master, which will happen, this would not make a good impression.

You make the assumption that GitHub users expect the master to be a release version. I don’t hink this holds true. Most people see the master branch in Git as what a “trunk” version in SVN used to be: the latest state of the project, i.e., not the latest release.

Just to pick a few large projects at random: NodeJS (https://github.com/nodejs/node), Linux (torvalds/linux), Rails (rails/rails), OpenSSL (openssl/openssl), Spark (apache/spark), ...

Most projects on GitHub use the master as “head of development” version. CAF is currently one of the exceptions but for no good reason, I think. Besides, developers usually don’t bother with the GitHub repo in the first place. They use one of the many more convenient packaging/dependency tools: conan.io, HomeBrew, Linux Packages, etc. We should expect devs that go out of their way to go visit and checkout the CAF repo explicitly to have an interest in the current state of development. Point in case: a recent user mistaking lack of activity in the master branch for lack of activity in the project [1] and pretty much every first-time PR targeted at master instead of develop.

Hiding the current trunk version in some branch violates the expectation of most visitors. Leaving the “path of least surprise” in programming or otherwise has to have solid justification (and large comment blocks in actual source code) and undeniable upsides or necessities. I fail to see major upsides in keeping the current `master/develop` split, so I still argue getting rid of `develop` for good.

    Dominik

[1] https://github.com/actor-framework/actor-framework/issues/598

To view this discussion on the web visit https://groups.google.com/d/msgid/caf-devel/AM4PR03MB1540441E52BA6368111ABB918D420%40AM4PR03MB1540.eurprd03.prod.outlook.com.

[Dominik Charousset]

FYI, I’ve updated the contributor guide and started to purge all references to the old `develop` branch.

Please file any new PR to `master` from here on out.

Dominik