Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
A
Actor Framework
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Operations
Operations
Metrics
Environments
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
cpp-libs
Actor Framework
Commits
90a18f93
Commit
90a18f93
authored
Apr 14, 2015
by
Matthias Vallentin
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Adapt contribution guidelines
parent
eacae4a5
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
82 additions
and
72 deletions
+82
-72
CONTRIBUTING.md
CONTRIBUTING.md
+82
-72
No files found.
CONTRIBUTING.md
View file @
90a18f93
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)
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment