Merge pull request #448 from saurabh6790/bench-docs

[docs] documentation for release strategy and contribution guidelines

bench/docs/contribution_guidelines.md

@@ -0,0 +1,46 @@
+# Contribution Guidelines
+
+### Introduction (for first timers)
+
+Thank you for your interesting in contributing to an open source project! Our world works on people taking initiative to contribute to the "commons" and contributing to open source means you are contributing to make things better for not only yourself, but everyone else too! So thank you for taking this initiative.
+
+Great projects also work because of great quality. Open source or not, the user really cares that things should work as they are advertised, and consistently. New features should follow the same pattern and so that users don't have to learn things again and again. 
+
+Developers who maintain open source also expect that you follow certain guidelines. These guidelines ensure that developers are able quickly give feedback on your contribution and how to make it better. Most probably you might have to go back and change a few things, but it will be in th interest of making this process better for everyone. So do be prepared for some back and forth.
+
+Happy contributing!
+
+### Feedback Policy
+
+We will strive for a "Zero Pull Request Pending" policy, inspired by "Zero Inbox". This means, that if the pull request is good, it will be merged within a day and if it does not meet the requirements, it will be closed.
+
+### Design Guides
+
+Please read the following design guidelines carefully when contributing:
+
+1. [Form Design Guidelines](https://github.com/frappe/erpnext/wiki/Form-Design-Guidelines)
+1. [How to break large contributions into smaller ones](https://github.com/frappe/erpnext/wiki/Cascading-Pull-Requests)
+
+### Pull Request Requirements
+
+1. **Test Cases:** Important to add test cases, even if its a very simple one that just calls the function. For UI, till we don't have Selenium testing setup, we need to see a screenshot / animated GIF.
+1. **UX:** If your change involves user experience, add a screenshot / narration / animated GIF.
+1. **Documentation:** Test Case must involve updating necessary documentation
+1. **Explanation:** Include explanation if there is a design change, explain the use case and why this suggested change is better. If you are including a new library or replacing one, please give sufficient reference of why the suggested library is better.
+1. **Demo:** Remember to update the demo script so that data related your feature is included in the demo.
+1. **Failing Tests:** This is simple, you must make sure all automated tests are passing.
+1. **Very Large Contribution:** It is very hard to accept and merge very large contributions, because there are too many lines of code to check and its implications can be large and unexpected. They way to contribute big features is to build them part by part. We can understand there are exceptions, but in most cases try and keep your pull-request to **30 lines of code** excluding tests and config files. **Use [Cascading Pull Requests](https://github.com/frappe/erpnext/wiki/Cascading-Pull-Requests)** for large features.
+1. **Incomplete Contributions must be hidden:** If the contribution is WIP or incomplete - which will most likely be the case, you can send small PRs as long as the user is not exposed to unfinished functionality. This will ensure that your code does not have build or other collateral issues. But these features must remain completely hidden to the user.
+1. **Incorrect Patches:** If your design involves schema change and you must include patches that update the data as per your new schema.
+1. **Incorrect Naming:** The naming of variables, models, fields etc must be consistent as per the existing design and semantics used in the system.
+1. **Translated Strings:** All user facing strings / text must be wrapped in the `__("")` function in javascript and `_("")` function in Python, so that it is shown as translated to the user.
+1. **Deprecated API:** The API used in the pull request must be the latest recommended methods and usage of globals like `cur_frm` must be avoided.
+1. **Whitespace and indentation:** The ERPNext and Frappe Project uses tabs (I know and we are sorry, but its too much effort to change it now and we don't want to lose the history). The indentation must be consistent whether you are writing Javascript or Python. Multi-line strings or expressions must also be consistently indented, not hanging like a bee hive at the end of the line. We just think the code looks a lot more stable that way.
+
+#### What if my Pull Request is closed?
+
+Don't worry, fix the problem and re-open it!
+
+#### Why do we follow this policy?
+
+This is because ERPNext is at a stage where it is being used by thousands of companies and introducing breaking changes can be harmful for everyone. Also we do not want to stop the speed of contributions and the best way to encourage contributors is to give fast feedback.

bench/docs/release_policy.md

@@ -0,0 +1,56 @@
+# Release Policy
+
+#### Create staging branch
+
+- On Wednesday morning, we will create a `staging` branch from develop branch. `staging` branch is a release candidate. All new features will first go from `develop` to `staging` and then `staging` to `master`.
+
+- Use the prepare-staging command to create staging branch
+```usage: bench prepare-staging APP```
+
+- Impact on branches ?
+  - merge all commits from develop branch to staging
+  - push merge commit back to develop
+
+- QA will use staging for testing.
+
+- Deploy staging branch on frappe.io
+
+- Only regression and security fixes can be cherry-picked into staging
+
+- Create a discuss post on what all new features or fixes going in next version.
+
+---
+
+#### Create release from staging
+- On Tuesday, we will release from staging to master.
+
+- Versioning:
+  - patch: Small fixes
+  - minor: For new features updates.
+  - major: If any API changes
+
+- Impact on branches:
+  - merge staging branch to master
+  - push merge commit back to staging branch
+  - push merge commit to develop branch
+  - push merge commit to hotfix branch
+
+- Use release command to create release,
+``` usage: bench release APP patch|minor|major --from-branch staging ```
+
+---
+
+#### Create release from hotfix
+- Depending on priority, hotfix release will take place.
+
+- Versioning:
+  - patch: Small fixes
+
+- Impact on branches:
+  - merge hotfix branch to master
+  - push merge commit back to staging branch
+  - push merge commit to develop branch
+  - push merge commit to staging branch
+
+- Use release command to create release,
+``` usage: bench release APP patch --from-branch hotfix ```

bench/docs/releasing_frappe_erpext.md

@@ -0,0 +1,39 @@
+# Releasing Frappe ERPNext
+
+* Make a new bench dedicated for releasing
+```
+bench init release-bench --frappe-path git@github.com:frappe/frappe.git
+```
+
+* Get ERPNext in the release bench
+```
+bench get-app erpnext git@github.com:frappe/erpnext.git
+```
+
+* Configure as release bench. Add this to the common_site_config.json
+```
+"release_bench": true,
+```
+
+* Add branches to update in common_site_config.json
+```
+"branches_to_update": {
+    "staging": ["develop", "hotfix"],
+    "hotfix": ["develop", "staging"]
+}
+```
+
+* Use the release commands to release
+```
+Usage: bench release [OPTIONS] APP BUMP_TYPE
+```
+
+* Arguments :
+  * _APP_ App name e.g [frappe|erpnext|yourapp]
+  * _BUMP_TYPE_ [major|minor|patch|stable|prerelease]
+* Options:
+  * --from-branch git develop branch, default is develop
+  * --to-branch git master branch, default is master
+  * --remote git remote, default is upstream
+  * --owner git owner, default is frappe
+  * --repo-name git repo name if different from app name