Repository: commons-math Updated Branches: refs/heads/master e0b2c86c8 -> 2c47a6995
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. Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/2c47a699 Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/2c47a699 Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/2c47a699 Branch: refs/heads/master Commit: 2c47a699547618132f06f8c9fef7fc0ebb1cb4e8 Parents: e0b2c86 Author: Gilles <er...@apache.org> Authored: Thu Feb 4 15:29:35 2016 +0100 Committer: Gilles <er...@apache.org> Committed: Thu Feb 4 15:29:35 2016 +0100 ---------------------------------------------------------------------- doc/development/development.howto.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/commons-math/blob/2c47a699/doc/development/development.howto.txt ---------------------------------------------------------------------- diff --git a/doc/development/development.howto.txt b/doc/development/development.howto.txt new file mode 100644 index 0000000..3f1ff71 --- /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.
