From 2c47a699547618132f06f8c9fef7fc0ebb1cb4e8 Mon Sep 17 00:00:00 2001 From: Gilles Date: Thu, 4 Feb 2016 15:29:35 +0100 Subject: [PATCH] Develoment model (using "git"). Basic policy has been agreed on in this thread: http://markmail.org/message/7lnus64entdwj4vo Additions are in order if and when handling of legacy code is decided. --- doc/development/development.howto.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/development/development.howto.txt diff --git a/doc/development/development.howto.txt b/doc/development/development.howto.txt new file mode 100644 index 000000000..3f1ff713b --- /dev/null +++ b/doc/development/development.howto.txt @@ -0,0 +1,23 @@ +This document summarizes a discussion that took place on the "dev" ML: + http://markmail.org/message/7lnus64entdwj4vo + +The conclusions reported here are based on ideas presented in this blog post: + http://nvie.com/posts/a-successful-git-branching-model/ + +1. The "master" branch can only contain released code; i.e. the only + accepted commits are the result of a merge from the "release" branch + (from a release candidate that passed a vote). +2. Contents that is candidate for being released must be merged into the + "release" branch, from the "development" branch. +3. The "development" branch collects all modifications that will be part + of the next release. + Usually, changes should not be committed directly to the "development" + branch; they should be merged from a branch specifically created for + that purpose (see next point). +4. Work on an identified issue (bug fix or new feature) must be done in a + new branch named after its corresponding report in the bug-tracking + system (JIRA), e.g. "feature-MATH-1319". + After completion, and in the absence of technical objections, the feature + branch is merged into the "development" branch, using the "--no-ff" git + option. + That feature branch is then deleted.