From 1335a83a380cd337ad536a7676cda8143661186c Mon Sep 17 00:00:00 2001
From: Fernando Mayer <fernandomayer@gmail.com>
Date: Tue, 15 Sep 2015 16:28:37 -0300
Subject: [PATCH] Rewrite information about the release branch

---
 CONTRIBUTING.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index ee5d669..e9f878c 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -16,11 +16,11 @@ two links: [A successful Git branching model][], and
 Basically, all the ongoing development is made in the `devel`
 branch. New features and bug fixes are made in additional (parallell)
 branches such like `feature/<num>`, where `<num>` is an incremental
-number. Feature branches are merged with the `devel` branch. When a new
-version is supposed to be ready for release, it is moved to the
-`release` branch, where final tests are made to guarantee it is
-stable. Only then it is moved to the `master` branch, where it receives
-a tag with the version number.
+number. Feature branches are merged with the `devel` branch, where final
+tests are made to guarantee it is stable. Only then it is moved to the
+`master` branch, where it receives a tag with the version number. Note
+that we don't use a `release` branch as in a traditional Gitflow
+workflow (this is the only difference).
 
 This way, users may opt to install the stable version, from the `master`
 branch, or they may install the development version from the `devel`
-- 
GitLab