From 02ccce08ec81a5286464d20c340f2563e1be397f Mon Sep 17 00:00:00 2001 From: Ali-RS Date: Thu, 11 Jul 2019 09:56:05 +0430 Subject: [PATCH] Updated CONTRIBUTING.md (#1139) * Updated CONTRIBUTING.md Added "Customs around integration, branching, tagging, and releases" section to contribution guide. * Clarify that the admonition to squash PRs is directed at integrators --- CONTRIBUTING.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7234481dd..abb84c53c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -22,6 +22,15 @@ p.s. We will try hold ourselves to a [certain standard](http://www.defmacro.org/ Developers in the Contributors team can push directly to Main instead of submitting pull requests, however for new features it is often a good idea to do a pull request as a means to get a last code review. +## Customs around integration, branching, tagging, and releases + +- Most pull requests are integrated directly into the master branch of the repository. +- Integrators should note, unless the history of the pull request is important, it should be integrated to a single commit using “squash and merge”. If the history is important, favor “rebase and merge”. Don’t create a merge commit unless GitHub cannot rebase the PR. +- For each major release (such as v3.0 or v3.3), an appropriately named release branch is created in the repository. +- For each minor (or “dot-dot”) release (such as v3.2.3), an appropriately named tag is created in the repository. +- In general, library changes that plausibly might break existing apps appear only in major releases, not minor ones. + + ## Building the engine 1. Install [Gradle](http://www.gradle.org/)