Skip to content

Latest commit

 

History

History
101 lines (73 loc) · 3.88 KB

CONTRIBUTING.md

File metadata and controls

101 lines (73 loc) · 3.88 KB
Raw

Table of Contents generated with DocToc

Welcome to Swift Fakes!

We're building standardized test doubles for Swift.

Swift Fakes should be easy to use and easy to maintain. Let's keep things simple and well-tested.

Reporting Bugs

Nothing is off-limits. If you're having a problem, we want to hear about it.

  • See a crash? File an issue.
  • Code isn't compiling, but you don't know why? Sounds like you should submit a new issue, friend.
  • Went to the kitchen, only to forget why you went in the first place? Better submit an issue.

Be sure to include in your issue:

  • Your Xcode version (eg - Xcode 15.3.0 15E204A)
  • Your version of Quick / Nimble / Swift Fakes (eg - v0.0.0 or git sha 7d0b8c21357839a8c5228863b77faecf709254a9)
  • What are the steps to reproduce this issue?
  • What platform are you using? (eg - OS X, iOS, watchOS, tvOS, visionOS)
  • If the problem is on a UI Testing Bundle, Unit Testing Bundle, or some other target configuration
  • Are you using Swift PM or some other package manager?

Building the Project

  • Open the Package.swift in xcode, or run swift build.

Pull Requests

  • Nothing is trivial. Submit pull requests for anything: typos, whitespace, you name it.
  • Not all pull requests will be merged, but all will be acknowledged. If no one has provided feedback on your request, ping one of the owners by name.
  • Make sure your pull request includes any necessary updates to the README or other documentation.
  • Be sure the unit tests pass before submitting your pull request. You can run all the unit tests using swift test.
  • The main branch will always support the stable Xcode version. Other branches will point to their corresponding versions they support.

Style Conventions

  • Indent using 4 spaces.
  • Keep lines 100 characters or shorter. Break long statements into shorter ones over multiple lines.

Core Members

If a few of your pull requests have been merged, and you'd like a controlling stake in the project, file an issue asking for write access to the repository.

Your conduct as a core member is your own responsibility, but here are some "ground rules":

  • Feel free to push whatever you want to main, and (if you have ownership permissions) to create any repositories you'd like.

    Ideally, however, all changes should be submitted as GitHub pull requests. No one should merge their own pull request, unless no other core members respond for at least a few days.

    Pull requests should be issued from personal forks. The Quick repo should be reserved for long-running feature branches.

    If you'd like to create a new repository, it'd be nice if you created a GitHub issue and gathered some feedback first.

  • It'd be awesome if you could review, provide feedback on, and close issues or pull requests submitted to the project. Please provide kind, constructive feedback. Please don't be sarcastic or snarky.

Read CODE_OF_CONDUCT.md for more in depth guidelines.

Creating a Release

The process is relatively straight forward, but here's is a useful checklist for tagging:

  • Run the release script: ./script/release A.B.C
  • The script create a new GitHub release with autogenerated release notes.
    • Edit the release notes, and add highlights. Be especially sure to call out any breaking changes.
  • Announce!