|
| 1 | +<!-- START doctoc generated TOC please keep comment here to allow auto update --> |
| 2 | +<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> |
| 3 | + |
| 4 | +- [Welcome to Nimble!](#welcome-to-nimble!) |
| 5 | + - [Reporting Bugs](#reporting-bugs) |
| 6 | + - [Building the Project](#building-the-project) |
| 7 | + - [Pull Requests](#pull-requests) |
| 8 | + - [Style Conventions](#style-conventions) |
| 9 | + - [Core Members](#core-members) |
| 10 | + - [Code of Conduct](#code-of-conduct) |
| 11 | + |
| 12 | +<!-- END doctoc generated TOC please keep comment here to allow auto update --> |
| 13 | + |
| 14 | +# Welcome to Nimble! |
| 15 | + |
| 16 | +We're building a testing framework for a new generation of Swift and |
| 17 | +Objective-C developers. |
| 18 | + |
| 19 | +Nimble should be easy to use and easy to maintain. Let's keep things |
| 20 | +simple and well-tested. |
| 21 | + |
| 22 | +**tl;dr:** If you've added a file to the project, make sure it's |
| 23 | +included in both the OS X and iOS targets. |
| 24 | + |
| 25 | +## Reporting Bugs |
| 26 | + |
| 27 | +Nothing is off-limits. If you're having a problem, we want to hear about |
| 28 | +it. |
| 29 | + |
| 30 | +- See a crash? File an issue. |
| 31 | +- Code isn't compiling, but you don't know why? Sounds like you should |
| 32 | + submit a new issue, bud. |
| 33 | +- Went to the kitchen, only to forget why you went in the first place? |
| 34 | + Better submit an issue. |
| 35 | + |
| 36 | +Be sure to include in your issue: |
| 37 | + |
| 38 | +- Your Xcode version (eg - Xcode 7.0.1 7A1001) |
| 39 | +- Your version of Nimble (eg - v2.0.0 or git sha `20a3f3b4e63cc8d97c92c4164bf36f2a2c9a6e1b`) |
| 40 | +- What are the steps to reproduce this issue? |
| 41 | +- What platform are you using? (eg - OS X, iOS, watchOS, tvOS) |
| 42 | +- If the problem is on a UI Testing Bundle, Unit Testing Bundle, or some other target configuration |
| 43 | +- Are you using carthage or cocoapods? |
| 44 | + |
| 45 | +## Building the Project |
| 46 | + |
| 47 | +- Use `Nimble.xcodeproj` to work on Nimble. |
| 48 | + |
| 49 | +## Pull Requests |
| 50 | + |
| 51 | +- Nothing is trivial. Submit pull requests for anything: typos, |
| 52 | + whitespace, you name it. |
| 53 | +- Not all pull requests will be merged, but all will be acknowledged. If |
| 54 | + no one has provided feedback on your request, ping one of the owners |
| 55 | + by name. |
| 56 | +- Make sure your pull request includes any necessary updates to the |
| 57 | + README or other documentation. |
| 58 | +- Be sure the unit tests for both the OS X and iOS targets of Nimble |
| 59 | + before submitting your pull request. You can run all the OS X & iOS unit |
| 60 | + tests using `./test`. |
| 61 | +- If you've added a file to the project, make sure it's included in both |
| 62 | + the OS X and iOS targets. |
| 63 | +- The `master` branch will always support the stable Xcode version. Other |
| 64 | + branches will point to their corresponding versions they support. |
| 65 | +- If you're making a configuration change, make sure to edit both the xcode |
| 66 | + project and the podspec file. |
| 67 | + |
| 68 | +### Style Conventions |
| 69 | + |
| 70 | +- Indent using 4 spaces. |
| 71 | +- Keep lines 100 characters or shorter. Break long statements into |
| 72 | + shorter ones over multiple lines. |
| 73 | +- In Objective-C, use `#pragma mark -` to mark public, internal, |
| 74 | + protocol, and superclass methods. |
| 75 | + |
| 76 | +## Core Members |
| 77 | + |
| 78 | +If a few of your pull requests have been merged, and you'd like a |
| 79 | +controlling stake in the project, file an issue asking for write access |
| 80 | +to the repository. |
| 81 | + |
| 82 | +### Code of Conduct |
| 83 | + |
| 84 | +Your conduct as a core member is your own responsibility, but here are |
| 85 | +some "ground rules": |
| 86 | + |
| 87 | +- Feel free to push whatever you want to master, and (if you have |
| 88 | + ownership permissions) to create any repositories you'd like. |
| 89 | + |
| 90 | + Ideally, however, all changes should be submitted as GitHub pull |
| 91 | + requests. No one should merge their own pull request, unless no |
| 92 | + other core members respond for at least a few days. |
| 93 | + |
| 94 | + If you'd like to create a new repository, it'd be nice if you created |
| 95 | + a GitHub issue and gathered some feedback first. |
| 96 | + |
| 97 | +- It'd be awesome if you could review, provide feedback on, and close |
| 98 | + issues or pull requests submitted to the project. Please provide kind, |
| 99 | + constructive feedback. Please don't be sarcastic or snarky. |
| 100 | + |
| 101 | +### Creating a Release |
| 102 | + |
| 103 | +The process is relatively straight forward, but here's is a useful checklist for tagging: |
| 104 | + |
| 105 | +- Look at changes from the previously tagged release and write release notes: `git log v0.4.0...HEAD` |
| 106 | +- Run the release script: `./script/release A.B.C release-notes-file` |
| 107 | +- The script will prompt you to create a new [GitHub release](https://github.com/Quick/Nimble/releases). |
| 108 | + - Use the same release notes you created for the tag, but tweak up formatting for GitHub. |
| 109 | +- Update [Quick](https://github.com/Quick/Quick) |
| 110 | + - Update Quick's submodule reference to the newly released Nimble version |
| 111 | + - Update Nimble version in `README.md` and Documentation in [Quick](https://github.com/Quick/Quick) if it's not a patch version update. |
| 112 | +- Announce! |
0 commit comments