From d2a5525da1792aa645582967b94f94f294a97e78 Mon Sep 17 00:00:00 2001 From: Sulka Haro Date: Thu, 7 Feb 2019 22:23:42 +0200 Subject: [PATCH] Merge master to dev (#4273) Merging changes made to Master since last release into Dev for a release --- CONTRIBUTING.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3088b08eed5b..4059e50100a8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -76,11 +76,15 @@ If in doubt, format your code with `js-beautify --indent-size 2 --comma-first - ## Create a prototype +<<<<<<< HEAD Fork cgm-remote-monitor and create a branch. You can create a branch using `git checkout -b wip/add-my-widget`. This creates a new branch called `wip/add-my-widget`. The `wip` stands for work in progress and is a common prefix so that we know what to expect when reviewing many branches. +======= +Fork cgm-remote-monitor and create a branch. You can create a branch using `git checkout -b wip/add-my-widget`. This creates a new branch called `wip/add-my-widget`. The `wip` stands for work in progress and is a common prefix so that when know what to expect when reviewing many branches. +>>>>>>> master ## Submit a pull request @@ -91,6 +95,7 @@ This can be done by checking your code `git commit -avm 'my improvements are her Now that the commits are available on github, you can click on the compare buttons on your fork to create a pull request. Make sure to select [Nightscout's `dev` branch](https://github.com/nightscout/cgm-remote-monitor/tree/dev). We assume all new Pull Requests are at least smoke tested by the author and all code in the PR actually works. +<<<<<<< HEAD Please include a description of what the features do and rationalize why the changes are needed. @@ -107,6 +112,20 @@ This can be done by committing your code `git commit -avm 'my improvements are here'`, and pushing it to the branch you created on your own fork. This will probably look something like `git push -u origin wip/add-my-widget`. +======= + +Please include a description of what the features do and rationalize why the changes are needed. + +If you add any new NPM module dependencies, you have to rationalize why there are needed - we prefer pull requests that reduce dependencies, not add them. + +When adding new features that add confugration options, please ensure the `README` document is amended with information on the new configuration. + +## Bug fixing + +If you've fixed a bug, please consider adding a unit test to the `/tests` folder that reproduces the original bug without the change. + +Try to identify the root cause of the issue and fix the issue. Pull requests that simply add null checks to hide issues are unlikely to be accepted. +>>>>>>> master Please include instructions how to test the changes. @@ -120,6 +139,7 @@ We encourage liberal use of the comments, including images where appropriate. Most cgm-remote-monitor hackers use github's ticketing system, along with Facebook cgm-in-the-cloud, and gitter. +<<<<<<< HEAD We use [git-flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow), with `master` as our production, stable branch, and `dev` is used to queue changes for upcoming releases. Everything else is done on branches, hopefully with names that indicate what to expect. @@ -131,6 +151,13 @@ the version correctly. See [sem-ver](https://semver.org/) for versioning strate Every commit is tested by Travis CI. We encourage adding tests to validate your design. We encourage discussing your use cases to help everyone get a better understanding of your design. +======= +We use git-flow, with `master` as our production, stable branch, and `dev` is used to queue up for upcoming releases. Everything else is done on branches, hopefully with names that indicate what to expect. + +Once `dev` has been reviewed and people feel it's time to release, we follow the git-flow release process, which creates a new tag and bumps the version correctly. See sem-ver for versioning strategy. + +Every commit is tested by travis. We encourage adding tests to validate your design. We encourage discussing your use cases to help everyone get a better understanding of your design. +>>>>>>> master ## Other Dev Tips