diff options
| -rw-r--r-- | CONTRIBUTING.md | 27 | ||||
| -rw-r--r-- | README.md | 19 |
2 files changed, 30 insertions, 16 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2f8ea41e8..4d8fd2d05 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,25 +1,28 @@ -# Contributing to SmartDeviceLink-iOS +# Contributing to SDL Projects -Third party contributions are essential for making this repository great. However, we do have a few guidelines we need contributors to follow. +Third party contributions are essential for making SDL great. However, we do have a few guidelines we need contributors to follow. ### Issues -If writing a bug report, please make sure [it has enough info](http://yourbugreportneedsmore.info). Include all relevant information. +If writing a bug report, please make sure <a href="http://yourbugreportneedsmore.info" target="_blank">it has enough info</a>. Include all relevant information. -If requesting a feature, understand that we appreciate the input! However, it may not immediately fit our roadmap, and it may take a while for us to get to your request, if we are able to at all. +If requesting a feature, understand that we appreciate the input! However, it may not immediately fit our roadmap, and it may take a while for us to get to your request. ### Gitflow -We use [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow) as our branch management system. The main points you should know are: +We use <a href="http://nvie.com/posts/a-successful-git-branching-model/">Gitflow</a> as our branch management system. Please follow gitflow's guidelines while contributing to any SDL project. ### Pull Requests -* Please follow the [SDL iOS Style Guide](https://github.com/smartdevicelink/SmartDeviceLink-iOS/wiki/Objective-C-Style-Guide) +* Please follow the repository's for all code and documentation. * All feature branches should be based on `develop` and have the format `feature/branch_name`. * Minor bug fixes, that is bug fixes that do not change, add, or remove any public API, should be based on `master` and have the format `hotfix/branch_name`. -* All pull requests should involve a single change. Pull Requests that involve multiple changes (it is our discretion what precisely this means) will be rejected with a reason. -* All commits should involve logical units. Please do not put all changed code in one commit, unless it is a very minor change. -* Work in progress pull requests should have "[WIP]" in front of the Pull Request title. When you believe the pull request is ready to merge, remove this tag and @mention `smartdevicelink/developers` to get it scheduled for review. -* If applicable, follow [this Pull Request's format](https://github.com/smartdevicelink/SmartDeviceLink-iOS/pull/45). -* Please document all code written. Write [objective-c style documentation](http://nshipster.com/documentation/) for methods (we use [VVDocumenter](https://github.com/onevcat/VVDocumenter-Xcode) to help out, and use inline code comments where it makes sense, i.e. for non-obvious code chunks. -* As of SDL iOS 4.0, all new code *must* be unit tested. We use [Quick](https://github.com/Quick/Quick), [Nimble](https://github.com/Quick/Nimble), and [OCMock](http://ocmock.org) currently. Bug fixes should have a test that fails previously and now passes. All new features should be covered. If your code does not pass tests, or regresses old tests, it will be rejected. +* All pull requests should implement a single feature or fix a single bug. Pull Requests that involve multiple changes (it is our discretion what precisely this means) will be rejected with a reason. +* All commits should separated into logical units, i.e. unrelated changes should be in different commits within a pull request. +* Work in progress pull requests should have "[WIP]" in front of the Pull Request title. When you believe the pull request is ready to merge, remove this tag and @mention the appropriate SDL team to schedule a review. +* All new code *must* include unit tests. Bug fixes should have a test that fails previously and now passes. All new features should be covered. If your code does not have tests, or regresses old tests, it will be rejected. +* A great example of a <a href="https://github.com/smartdevicelink/SmartDeviceLink-iOS/pull/45" target="_blank">pull request can be found here</a>. ### Contributor's License Agreement (CLA) In order to accept Pull Requests from contributors, you must first sign [the Contributor's License Agreement](https://docs.google.com/forms/d/1VNR8EUd5b46cQ7uNbCq1fJmnu0askNpUp5dudLKRGpU/viewform). If you need to make a change to information that you entered, [please contact us](mailto:justin@livio.io). + +### Repository Specific Guidelines + * <a href="https://github.com/smartdevicelink/sdl_ios/wiki/Objective-C-Style-Guide" target="blank">iOS Style Guide</a> + * Please document all code written using [Objective-C style documentation](http://nshipster.com/documentation/) for methods (we use [VVDocumenter](https://github.com/onevcat/VVDocumenter-Xcode) for methods and use inline code comments where it makes sense, i.e. for non-obvious code chunks. @@ -1,8 +1,19 @@ -SDL iOS -======= +##### Note: Please see the [develop](https://github.com/smartdevicelink/sdl_ios/tree/develop) branch of sdl_ios for the most recent version. Significant changes have been made since the latest stable release and the in-progress develop branch. When released, it will include distribution via Carthage and Cocoapods. -SmartDeviceLink iOS Proxy +# SmartDeviceLink (SDL) + +SmartDeviceLink (SDL) is a standard set of protocols and messages that connect applications on a smartphone to a vehicle head unit. This messaging enables a consumer to interact with their application using common in-vehicle interfaces such as a touch screen display, embedded voice recognition, steering wheel controls and various vehicle knobs and buttons. There are three main components that make up the SDL ecosystem. + + * The [Core](https://github.com/smartdevicelink/sdl_core) component is the software which Vehicle Manufacturers (OEMs) implement in their vehicle head units. Integrating this component into their head unit and HMI based on a set of guidelines and templates enables access to various smartphone applications. + * The optional [SDL Server](https://github.com/smartdevicelink/sdl_server) can be used by Vehicle OEMs to update application policies and gather usage information for connected applications. + * The [iOS](https://github.com/smartdevicelink/sdl_ios) and [Android](https://github.com/smartdevicelink/sdl_android) libraries are implemented by app developers into their applications to enable command and control via the connected head unit. + +## Mobile Proxy + +The mobile library component of SDL is meant to run on the end user’s smart-device from within SDL enabled apps. The library allows the apps to connect to SDL enabled head-units and hardware through bluetooth, USB, and TCP. Once the library establishes a connection between the smart device and head-unit through the preferred method of transport, the two components are able to communicate using the SDL defined protocol. The app integrating this library project is then able to expose its functionality to the head-unit through text, media, and other interactive elements. + +## SDL iOS We're still working on creating documentation for each of these individual repositories, but in the meantime, you can find more information about SmartDeviceLink [on the SDL Core README](https://github.com/smartdevicelink/sdl_core/blob/master/README.md) and [on Genivi](http://projects.genivi.org/smartdevicelink/about). -To get started with testing, make sure that you have [Carthage](https://github.com/Carthage/Carthage) installed via [Homebrew](http://brew.sh/) (`brew update` `brew install carthage`), then run `carthage bootstrap` in the root directory of the repository on your local system. You will then have to drag in `Quick.framework` and `Nimble.framework` to the "Link Binaries with Libraries" build phase. For more information, see the [Carthage Github page](https://github.com/Carthage/Carthage). +This project uses [Semantic Versioning](http://semver.org/). |