-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
6 changed files
with
248 additions
and
12 deletions.
There are no files selected for viewing
Validating CODEOWNERS rules …
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
# Default code owners for the entire repository | ||
* @gSrikar @AshutoshAJ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,43 @@ | ||
# Code of Conduct | ||
|
||
## Our Pledge | ||
|
||
We, as members, contributors, and maintainers of this IOS repository, pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. | ||
|
||
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. | ||
|
||
## Our Standards | ||
|
||
Examples of behavior that contributes to creating a positive environment include: | ||
|
||
- Using welcoming and inclusive language | ||
- Being respectful of differing viewpoints and experiences | ||
- Gracefully accepting constructive criticism | ||
- Focusing on what is best for the community | ||
- Showing empathy towards other community members | ||
|
||
Examples of unacceptable behavior include: | ||
|
||
- The use of sexualized language or imagery and unwelcome sexual attention or advances | ||
- Trolling, insulting or derogatory comments, and personal or political attacks | ||
- Public or private harassment | ||
- Publishing others' private information, such as a physical or email address, without their explicit permission | ||
- Other conduct which could reasonably be considered inappropriate in a professional setting | ||
|
||
## Enforcement Responsibilities | ||
|
||
Project maintainers are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. | ||
|
||
## Scope | ||
|
||
This Code of Conduct applies within all project spaces and applies when an individual is representing the project or its community in public spaces. Examples include using the project’s GitHub repository, submitting issues, or engaging in discussions related to this Android repository. | ||
|
||
## Enforcement | ||
|
||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the HR team at hr@finbox.in. All complaints will be reviewed and investigated promptly and fairly. | ||
|
||
All project maintainers are obligated to respect the privacy and security of the reporter of any incident. | ||
|
||
## Attribution | ||
|
||
This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,134 @@ | ||
# Contributing to DeviceConnect IOS SDK | ||
|
||
We value your contributions to the IOS project! This guide will help ensure that our team maintains high standards and a smooth workflow. Please follow these guidelines when contributing to the project. | ||
|
||
## Table of Contents | ||
1. [Getting Started](#getting-started) | ||
2. [Code of Conduct](#code-of-conduct) | ||
3. [How to Contribute](#how-to-contribute) | ||
- [Issues](#issues) | ||
- [Feature Requests](#feature-requests) | ||
- [Pull Requests](#pull-requests) | ||
4. [Coding Guidelines](#coding-guidelines) | ||
5. [Testing](#testing) | ||
6. [Communication](#communication) | ||
|
||
## Getting Started | ||
|
||
Before contributing, make sure you have the latest version of the repository. The project uses standard tools such as: | ||
- **Xcode**: Use the latest stable version. | ||
- **CocoaPods**: Download the latest stable version. | ||
- **Swift Package Manager**: Download the latest Swift version which comes with Swift Package Manager. | ||
|
||
To get the repository up and running: | ||
|
||
1. Clone the repository: | ||
```bash | ||
git clone https://github.com/finbox-in/device-connect-ios-sdk.git | ||
2. Install dependencies (Cocoapod or Swift package manager) | ||
```bash | ||
pod install | ||
``` | ||
or | ||
```bash | ||
swift package resolve | ||
3. Open the project in XCode and ensure all dependencies are correctly configured. | ||
## Code of Conduct | ||
Please review our [Code of Conduct](CODE_OF_CONDUCT.md) to understand our expectations for behavior when contributing to the project. We aim to foster a positive and respectful environment. | ||
## How to Contribute | ||
### Issues | ||
1. Provide a clear and descriptive title. | ||
2. Include steps to reproduce, expected behavior, and actual behavior. | ||
3. Attach relevant logs, screenshots, or crash reports (if applicable). | ||
4. Assign appropriate labels (e.g., `bug`, `enchancement`, `documentation`). | ||
### Feature Requests | ||
1. Describe the feature and its benefit to the project or users. | ||
2. Include design documents, sketches, or screenshots to illustrate the idea. | ||
3. Before submitting, ensure the issue or feature has not already been raised in the repository. | ||
### Pull Requests | ||
To contribute new features, improvements, or bug fixes, follow these steps: | ||
1. Create a JIRA ticket in the SDK project. | ||
2. Create your branch with name that starts with the JIRA ticket number: | ||
```bash | ||
git checkout -b SDK-XXX-your-feature-name | ||
3. Make your changes while adhering to our [coding guidelines](#coding-guidelines). | ||
4. Submit the pull request (PR) with the following: | ||
- A clear title and description of the changes. | ||
- Add all the related JIRA ticket numbers. | ||
- Link any related issues. | ||
- Fill all the details in the PR template. | ||
- Mention details about all the devices tested. | ||
- Ensure your code passes all tests. | ||
5. PR Review Process: | ||
- PRs will undergo a review process by the maintainers. Be open to feedback and make adjustments as needed. | ||
- Keep your branch up to date with `main` before final approval. | ||
6. Merging: | ||
- Only maintainers can merge PRs after ensuring code quality and testing have been completed. | ||
|
||
|
||
## Coding Guidelines | ||
|
||
To ensure the quality and consistency of the codebase, follow these guidelines: | ||
|
||
- Code Style: | ||
- Use **Swift** for new code development and avoid Objective-C unless necessary. | ||
- Follow the [Swift API Design Guidelines](https://www.swift.org/documentation/api-design-guidelines/) and [SwiftLint](https://realm.github.io/SwiftLint/) rules for code formatting. | ||
- File Structure: | ||
- Organize your files logically based on feature modules and follow the existing folder structure. | ||
- Comments: | ||
- Comment your code where necessary to explain complex logic or important decisions. | ||
- Commit Messages: | ||
- Use meaningful commit messages that explain why a change was made, not just what was changed. | ||
- Example format: `SDK-XXX Fix user login crash on iOS 14`. | ||
- Branch Naming: | ||
- Use descriptive branch names like `SDK-XXX-your-feature-name` or `SDK-XXX-issue-123`. | ||
|
||
|
||
## Testing | ||
|
||
Ensure that your changes do not introduce new bugs. Follow these testing guidelines: | ||
|
||
1. Unit Tests: | ||
- Write unit tests for any new or modified functionality. | ||
- Use **XCTest** for testing where appropriate. | ||
- Run tests locally before submitting: | ||
``bash | ||
xcodebuild test | ||
2. Manual Testing: | ||
- Test your changes on different IOS versions and various screen sizes. | ||
- Test both in simulatoes and physical devices where possible. | ||
3. Lint Checks: | ||
- Run `SwiftLint` to ensure code quality: | ||
```bash | ||
swiftlint | ||
4. Continuous Integration: | ||
- Ensure that the project builds successfully in our CI environment (e.g., GitHub Actions or Jenkins). | ||
## Communication | ||
We use the following channels to communicate and collaborate on the project: | ||
- Slack/Teams: For real-time discussions and general questions. | ||
- Email: For detailed feedback or specific concerns (use srikar@finbox.in). | ||
- JIRA Tickets: For tracking bugs, enhancements, and documentation. | ||
Be proactive in reaching out if you need help or clarification. | ||
------------------------------- | ||
Thank you for contributing to the project! Your efforts help us maintain a robust and well-functioning IOS SDK. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,29 @@ | ||
# Releasing | ||
|
||
1. Update the `spec.version` in `RiskManager.podspec` to the release version. | ||
|
||
2. Update the `CHANGELOG.md` | ||
|
||
3. Commit | ||
|
||
``` | ||
$ git commit -am "Prepare version X.Y.Z" | ||
``` | ||
|
||
5. Tag | ||
|
||
``` | ||
$ git tag -am "Version X.Y.Z" X.Y.Z | ||
``` | ||
|
||
6. Push | ||
|
||
``` | ||
$ git push && git push --tags | ||
``` | ||
|
||
7. Publish the pod | ||
|
||
``` | ||
$ pod trunk push RiskManager.podspec --allow-warnings | ||
``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
# Security Policy | ||
|
||
## Supported Versions | ||
|
||
We regularly release updates to the iOS project to ensure the latest security patches and improvements are available. Please make sure you're using the most recent version of the app or framework to benefit from the latest security enhancements. | ||
|
||
## Reporting a Vulnerability | ||
|
||
We take the security of our iOS project seriously. If you discover a security vulnerability, we ask you to responsibly disclose it to us so we can investigate and fix it as soon as possible. | ||
|
||
### How to Report | ||
|
||
**Please send an email to srikar@finbox.in with the following details**: | ||
- Include a description of the vulnerability, steps to reproduce it, and any potential impact. | ||
- Do **not** post the details in public GitHub issues, as it may expose the vulnerability to malicious actors. | ||
|
||
### What Happens Next? | ||
|
||
- We will acknowledge receipt of your report within 48 hours. | ||
- We will investigate and provide an estimated timeline for addressing the issue. | ||
- Once the vulnerability is resolved, we will release a patch or security update and inform you of the fix. | ||
- If applicable, we will credit you for the report (unless you prefer to remain anonymous). | ||
|
||
## Security Best Practices | ||
|
||
To ensure your project remains secure, we recommend the following best practices: | ||
|
||
- **Use Keychain Services**: Secure sensitive data like passwords, tokens, and keys in the iOS Keychain. | ||
- **Regular Dependency Updates**: Keep third-party libraries (e.g., CocoaPods, Swift Package Manager) up-to-date to minimize the risk of vulnerabilities in external code. | ||
- **App Transport Security (ATS)**: Enforce ATS to ensure secure network connections within the app. | ||
- **Static Analysis Tools**: Use tools like [SwiftLint](https://github.com/realm/SwiftLint) or [SonarQube](https://www.sonarsource.com/products/sonarqube/) to identify potential security issues in the codebase. | ||
- **Penetration Testing**: Regularly perform penetration testing to find and fix potential vulnerabilities. | ||
|
||
## Acknowledgements | ||
|
||
We appreciate your efforts to responsibly disclose security vulnerabilities and for helping to keep our iOS project secure. | ||
|
||
Thank you! |