If you're interested in contributing to PLCrashReporter, welcome! The project's source code can be found in the PLCrashReporter Git Repository, hosted by Plausible Labs. Additionally, a live mirror is maintained on GitHub.
At a minimum we recommend skimming the project's Development Standards. PLCrashReporter is a complicated project, with a lot of moving pieces, and very little room for error — keep in mind that PLCrashReporter is used after a program has already crashed once, and the last thing we want to do is make things worse!
If you're interested in tackling a large project, or working on changes that may have a widespread impact on the code base, then we recommend reaching out on the project mailing list, issue tracker, or IRC regarding your area of interest; we're happy to provide assistance in getting started. It's very helpful to talk to us as early as possible, to both avoid duplication of effort, and so that we can assist in getting your changes as close to mergeable as possible on the first try.
The Development Workflow
The standard development workflow on PLCrashReporter is as follows:
- Select an existing issue (or file a new issue) on the project issue tracker.
- For significant changes, consider discussing your implementation plan with a project developer (eg, via the issue tracker, project mailing list, or IRC)
- Review the project Development Standards.
- Create a new feature branch for the changes you will be submitting. This can either be done via a local clone of the PLCrashReporter Git Repository, or in a fork of the GitHub Mirror.
- Verify that your unit tests pass, and no regressions have been introduced, on all supported architectures to which you have reasonable access. At the time of this writing, PLCrashReporter supports:
- Mac OS X 10.5 - 10.9+
- iOS 4.3 - 7.0+
- ARM64 (ARMv8)
- iOS Simulator 4.3 - 7.0+
- Mac OS X 10.5 - 10.9+
- Generate a patch for submission:
- Using git format-patch (preferred) to generate a single patch file, or
- Create a pull request on GitHub
- Submit an update to the issue tracker containing your proposed patch, or follow up on the mailing list if you wish to discuss the changes prior to submitting them.
Since PLCrashReporter uses git, you're free to use whatever mechanism you find convenient while developing a local patch. That said, please don't feel compelled to rebase your branch before sending us a patch or creating a pull request. We only care if the final code is clean, not your history. If you tried a few different approaches before settling on the final code, keeping that history can help prevent somebody else from needlessly trying the same thing, or help a later reader understand why the code was written that way.
Versioning and Branching Model
PLCrashReporter uses a simple release branching model. Note that we never rebase or delete branches and tags, as to maintain an accurate version control history. More details are provided in the shared Plausible Development Standards.
|master||The current in-development code.||Like all other branches, the code in master must compile and pass all unit and integration tests.|
An in-development feature.
|This code will be merged into master.|
|bugfix/PLCR-<issue#>-description||An in-development bugfix.|
This code will be merged into master, and may also be merged into existing supported release branches.
|release/plcrashreporter-major.minor||A release maintenance branch.||All minor release for the given major.minor will be developed and released from this branch.|
We require that committed code pass all tests and compile cleanly.