Commit ec6430b8 authored by Dominik Charousset's avatar Dominik Charousset

Remove references to develop branch

Starting with this commit, CAF will no longer use a separate `develop`
branch for its trunk version.
parent 28514815
This document specifies how to contribute code to CAF. This document specifies how to contribute code to CAF.
Git Workflow Git Workflow
============ ============
Our git workflow encompasses the following key aspects. (For general git Please adhere to the following Git naming and commit message conventions.
style guidelines, see <https://github.com/agis-/git-style-guide>.) Having a consistent work flow and style reduces friction and makes organizing
contributions a lot easier for all sides.
Branches
--------
- Our main branch is `master`. It reflects the latest development changes for
the next release and should always compile. Nightly versions use the
`master`. Users looking for a production-ready state are encouraged to use
the latest release version instead.
- Push trivial bugfixes (e.g. typos, missing includes, etc.) consisting of a
single commit directly to `master`. Otherwise, implement your changes in a
topic or bugfix branch and file a pull request on GitHub.
- Implement new features and non-trivial changes in a *topic branch* with
naming convention `topic/short-description`.
- Implement fixes for existing issues in a *bugfix branch* with naming
convention `issue/$num`, where `$num` is the issue ID on GitHub.
- The `master` branch always reflects a *production-ready* state, i.e., - Simply use a fork of CAF if you are an external contributor.
the latest release version.
- The `develop` branch is the main development branch. A maintainer merges into Pull Requests
`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`. Check the following steps to prepare for a merge into `master` after completing
work in a topic or bugfix branch (or fork).
- Fixes for critical issues can be pushed to `master` (and `develop`) - Squash your commits into a single one if necessary. Each commit should
after talking to a maintainer (and then cause a new release immediately). represent a coherent set of changes.
- For new features and non-trivial fixes, CAF uses *topic branches* which - Wait for a code review and the test results of our CI.
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 - Address any review feedback and fix all issues reported by the CI.
+ 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
- A maintainer will merge the pull request when all issues are resolved.
Commit Message Style Commit Message Style
-------------------- --------------------
- The first line succintly summarizes the changes in no more than 50 - Summarize the changes in no more than 50 characters in the first line.
characters. It is capitalized and written in and imperative present tense: Capitalize and write in an imperative present tense, e.g., "Fix bug" as
e.g., "Fix bug" as opposed to "Fixes bug" or "Fixed bug". opposed to "Fixes bug" or "Fixed bug".
- The first line does not contain a dot at the end. (Think of it as the header - Suppress the dot at the end of the first line. Think of it as the header of
of the following description). the following description.
- The second line is empty. - Leave the second line empty.
- Optional long descriptions as full sentences begin on the third line,
indented at 72 characters per line.
- Optionally add a long description written in full sentences beginning on the
third line. Indent at 72 characters per line.
Coding Style Coding Style
============ ============
When contributing source code, please adhere to the following coding style, When contributing source code, please adhere to the following coding style,
which is loosely based on the [Google C++ Style which is loosely based on the [Google C++ Style
Guide](https://google.github.io/styleguide/cppguide.html) and the Guide](https://google.github.io/styleguide/cppguide.html) and the coding
coding conventions used by the C++ Standard Library. conventions used by the C++ Standard Library.
Example for the Impatient Example for the Impatient
------------------------- -------------------------
...@@ -174,31 +181,30 @@ void my_class::do_something_else() noexcept { ...@@ -174,31 +181,30 @@ void my_class::do_something_else() noexcept {
``` ```
General General
------- -------
- Use 2 spaces per indentation level. - Use 2 spaces per indentation level.
- The maximum number of characters per line is 80. - Use at most 80 characters per line.
- No tabs, ever. - Never use tabs.
- Never use C-style casts. - Never use C-style casts.
- Vertical whitespaces separate functions and are not used inside functions: - Never declare more than one variable per line.
use comments to document logical blocks.
- Header filenames end in `.hpp`, implementation files end in `.cpp`. - Only separate functions with vertical whitespaces and use comments to
document logcial blocks inside functions.
- Never declare more than one variable per line. - Use `.hpp` as suffix for header files and `.cpp` as suffix for implementation
files.
- `*` and `&` bind to the *type*, e.g., `const std::string& arg`. - Bind `*` and `&` to the *type*, e.g., `const std::string& arg`.
- Namespaces and access modifiers (e.g., `public`) do not increase the - Never increase the indentation level for namespaces and access modifiers.
indentation level.
- In a class, use the order `public`, `protected`, and then `private`. - Use the order `public`, `protected`, and then `private` in classes.
- Always use `auto` to declare a variable unless you cannot initialize it - Always use `auto` to declare a variable unless you cannot initialize it
immediately or if you actually want a type conversion. In the latter case, immediately or if you actually want a type conversion. In the latter case,
...@@ -206,12 +212,12 @@ General ...@@ -206,12 +212,12 @@ General
- Never use unwrapped, manual resource management such as `new` and `delete`. - Never use unwrapped, manual resource management such as `new` and `delete`.
- Never use `typedef`; always write `using T = X` in favor of `typedef X T`. - Prefer `using T = X` over `typedef X T`.
- Keywords are always followed by a whitespace: `if (...)`, `template <...>`, - Insert a whitespaces after keywords: `if (...)`, `template <...>`,
`while (...)`, etc. `while (...)`, etc.
- Opening braces belong to the same line: - Put opening braces on the same line:
```cpp ```cpp
void foo() { void foo() {
...@@ -220,52 +226,54 @@ General ...@@ -220,52 +226,54 @@ General
``` ```
- Use standard order for readability: C standard libraries, C++ standard - Use standard order for readability: C standard libraries, C++ standard
libraries, other libraries, (your) CAF headers: libraries, OS-specific headers (usually guarded by `ifdef`), other libraries,
and finally (your) CAF headers. Include `caf/config.hpp` before the standard
headers if you need to include platform-dependent headers. Use angle brackets
for system includes and doublequotes otherwise.
```cpp ```cpp
// some .hpp file // example.hpp
#include <sys/types.h>
#include <vector> #include <vector>
#include <sys/types.h>
#include "3rd/party.h" #include "3rd/party.h"
#include "caf/fwd.hpp" #include "caf/fwd.hpp"
``` ```
CAF includes should always be in doublequotes, whereas system-wide includes Put the implemented header always first in a `.cpp` file.
in angle brackets. In a `.cpp` file, the implemented header always comes first
and the header `caf/config.hpp` can be included second if you need
platform-dependent headers:
```cpp ```cpp
// example.cpp // example.cpp
#include "caf/example.hpp" // header related to this .cpp file #include "caf/example.hpp" // header for this .cpp file
#include "caf/config.hpp" #include "caf/config.hpp" // needed for #ifdef guards
#include <algorithm>
#ifdef CAF_WINDOWS #ifdef CAF_WINDOWS
#include <windows.h> #include <windows.h>
#else #else
#include <sys/socket.h> #include <sys/socket.h>
#endif #endif
#include <algorithm>
#include "some/other/library.h" #include "some/other/library.h"
#include "caf/actor.hpp" #include "caf/actor.hpp"
``` ```
- When declaring a function, the order of parameters is: outputs, then inputs. - Put output parameters in functions before input parameters if unavoidable.
This follows the parameter order from the STL. This follows the parameter order from the STL.
- Protect single-argument constructors with `explicit` to avoid implicit conversions. - Protect single-argument constructors with `explicit` to avoid implicit
conversions.
- Use noexcept whenever it makes sense, in particular for move construction and assignment, - Use `noexcept` whenever it makes sense and as long as it does not limit future
as long as it does not limit future design space. design space. Move construction and assignment are natural candidates for
`noexcept`.
Naming Naming
------ ------
...@@ -279,8 +287,8 @@ Naming ...@@ -279,8 +287,8 @@ Naming
should be "command" verbs. Classes used to implement metaprogramming should be "command" verbs. Classes used to implement metaprogramming
functions also should use verbs, e.g., `remove_const`. functions also should use verbs, e.g., `remove_const`.
- Private and protected member variables use the suffix `_` while getter *and* setter - Private and protected member variables use the suffix `_` while getter *and*
functions use the name without suffix: setter functions use the name without suffix:
```cpp ```cpp
class person { class person {
...@@ -309,7 +317,6 @@ Naming ...@@ -309,7 +317,6 @@ Naming
} }
``` ```
Headers Headers
------- -------
...@@ -335,7 +342,6 @@ Headers ...@@ -335,7 +342,6 @@ Headers
- Use `inline` for small functions (rule of thumb: 10 lines or less). - Use `inline` for small functions (rule of thumb: 10 lines or less).
Breaking Statements Breaking Statements
------------------- -------------------
...@@ -373,7 +379,6 @@ Breaking Statements ...@@ -373,7 +379,6 @@ Breaking Statements
} }
``` ```
Template Metaprogramming Template Metaprogramming
------------------------ ------------------------
...@@ -419,7 +424,6 @@ extra rules for formatting metaprogramming code. ...@@ -419,7 +424,6 @@ extra rules for formatting metaprogramming code.
ResponseHandleTag>; ResponseHandleTag>;
``` ```
Preprocessor Macros Preprocessor Macros
------------------- -------------------
...@@ -428,16 +432,14 @@ Preprocessor Macros ...@@ -428,16 +432,14 @@ Preprocessor Macros
- Macro names use the form `CAF_<COMPONENT>_<NAME>`. - Macro names use the form `CAF_<COMPONENT>_<NAME>`.
Comments Comments
-------- --------
- Doxygen comments start with `///`. - Start Doxygen comments with `///`.
- Use Markdown instead of Doxygen formatters. - Use Markdown instead of Doxygen formatters.
- Use `@cmd` rather than `\cmd`. - Use `@cmd` rather than `\cmd`.
- Use `//` to define basic comments that should not be - Use `//` to define basic comments that should not be processed by Doxygen.
swallowed by Doxygen.
...@@ -87,7 +87,7 @@ echo "\ ...@@ -87,7 +87,7 @@ echo "\
\____/_/ \_|_| \____/_/ \_|_|
This script expects to run at the root directory of a Git clone of CAF. This script expects to run at the root directory of a Git clone of CAF.
The current repository must be develop, there must be no untracked file, The current repository must be master. There must be no untracked file
and the working tree status must be equal to the current HEAD commit. and the working tree status must be equal to the current HEAD commit.
Further, the script expects a relase_note.md file in the current directory Further, the script expects a relase_note.md file in the current directory
with the developer blog checked out one level above, i.e.: with the developer blog checked out one level above, i.e.:
...@@ -106,6 +106,10 @@ with the developer blog checked out one level above, i.e.: ...@@ -106,6 +106,10 @@ with the developer blog checked out one level above, i.e.:
" "
if [ $(git rev-parse --abbrev-ref HEAD) != "master" ]; then
raise_error "not in master branch"
fi
# assumed files # assumed files
token_path="$HOME/.github-oauth-token" token_path="$HOME/.github-oauth-token"
blog_msg="blog_release_note.md" blog_msg="blog_release_note.md"
...@@ -166,10 +170,6 @@ git commit -a -m \"Change version to $1\" ...@@ -166,10 +170,6 @@ git commit -a -m \"Change version to $1\"
git push git push
git tag $tag_version git tag $tag_version
git push origin --tags git push origin --tags
git checkout master
git merge develop
git push
git checkout develop
curl --data '$github_json' https://api.github.com/repos/actor-framework/actor-framework/releases?access_token=$token curl --data '$github_json' https://api.github.com/repos/actor-framework/actor-framework/releases?access_token=$token
" > .make-release-steps.bash " > .make-release-steps.bash
......
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