Commit 90a18f93 authored by Matthias Vallentin's avatar Matthias Vallentin

Adapt contribution guidelines

parent eacae4a5
This document specifies the coding style for the C++ Actor Framework.
The style is loosely based on the
[Google C++ Style Guide](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml)
and the coding conventions used by the STL.
This document specifies how to contribute code to this repository.
Git Workflow
============
CAF's git workflow encompasses the following key aspects. (For general git
style guidelines, see https://github.com/agis-/git-style-guide.)
- The `master` branch always reflects a *production-ready* state, i.e.,
the latest release version.
- The `develop` branch is the main development branch. A maintainer merges into
`master` for a new release when it reaches a stable point. The `develop`
branch reflects the latest state of development and should always compile.
- Simple bugfixes consisting of a single commit can be pushed to `develop`.
- Fixes for critical issues can be pushed to `master` (and `develop`)
after talking to a maintainer (and then cause a new release immediately).
- For new features and non-trivial fixes, CAF uses *topic branches* which
branch off `develop` with a naming convention of `topic/short-description`.
After completing work in a topic branch, check the following steps to prepare
for a merge back into `develop`:
+ Squash your commits into a single one if necessary
+ Create a pull request to `develop` on github
+ Wait for the results of Jenkins and fix any reported issues
+ Ask a maintainer to review your work after Jenkins greelights your changes
+ Address the feedback articulated during the review
+ A maintainer will merge the topic branch into `develop` after it passes the
code review
Commit Message Style
--------------------
- The first line succintly summarizes the changes in no more than 50
characters. It is capitalized and written in and imperative present tense:
e.g., "Fix bug" as opposed to "Fixes bug" or "Fixed bug".
- The second line is empty.
- Optional long descriptions as full sentences begin on the third line,
indented at 72 characters per line.
Coding Style
============
When contributing source code, please adhere to the following coding style,
whwich is loosely based on the [Google C++ Style
Guide](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml) and the
coding conventions used by the STL.
Example for the Impatient
=========================
-------------------------
```cpp
// libcaf_example/caf/example/my_class.hpp
......@@ -135,7 +187,7 @@ void::my_class::do_something_else() {
General rules
=============
-------------
- Use 2 spaces per indentation level.
......@@ -204,7 +256,7 @@ General rules
Naming
======
------
- Class names, constants, and function names are all-lowercase with underscores.
......@@ -251,7 +303,7 @@ Naming
Headers
=======
-------
- Each `.cpp` file has an associated `.hpp` file.
Exceptions to this rule are unit tests and `main.cpp` files.
......@@ -277,7 +329,7 @@ Headers
Breaking Statements
===================
-------------------
- Break constructor initializers after the comma, use four spaces for
indentation, and place each initializer on its own line (unless you don't
......@@ -315,7 +367,7 @@ Breaking Statements
Template Metaprogramming
========================
------------------------
Despite its power, template metaprogramming came to the language pretty
much by accident. Templates were never meant to be used for compile-time
......@@ -361,7 +413,7 @@ extra rules for formatting metaprogramming code.
Rvalue References
=================
-----------------
- Use rvalue references whenever it makes sense.
......@@ -369,51 +421,9 @@ Rvalue References
Preprocessor Macros
===================
-------------------
- Use macros if and only if you can't get the same result by using inline
functions or proper constants.
- Macro names use the form `CAF_<COMPONENT>_<NAME>`.
General Git Rules
=================
- The first line is a capitalized summary and has at most 50 characters.
- The second line is left empty.
- Optional long descriptions begin on the third line with a at most 72
characters per line.
- Write commit messages in the imperative: "Fix bug" and not "Fixes bug"
or "Fixed bug".
Git Branches and Work Flow
==========================
- The `master` branch always reflects a *production-ready* state, i.e.,
the latest release version.
- The `develop` branch is the main branch. Every time it reaches a stable
point it is merged back to `master` for a new release. The `develop` branch
reflects the latest state of development and should always compile.
- Simple bugfixes consisting of a single commit can be pushed to `develop`.
- Fixes for critical issues can be pushed to the `master` (and `develop`)
branch after talking to the maintainer
(and then cause a new release immediately).
- New features or non-trivial fixes are developed in a *topic branch* using
the naming convention `topic/short-description`. Topic branches are merged
off from `develop`. Finishing topic branches includes these steps:
+ Create a *pull request* to `develop` on GitHub
+ Wait for the results of Jenkins and fix any issues that might come up
+ Squash your commits if necessary once Jenkins succeeds
+ Ask the maintainer to review your changes if you have green light from
Jenkins and a clean Git history for your work
+ The maintainer will merge the topic branch back into `develop` after the
review phase is done (and you once again have a clean Git history)
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment