|
1 |
| -# DynamicPPL |
| 1 | +# DynamicPPL.jl |
2 | 2 |
|
3 | 3 | [](https://travis-ci.com/TuringLang/DynamicPPL.jl)
|
| 4 | +[](https://github.com/TuringLang/DynamicPPL.jl/actions?query=workflow%3ADynamicPPL-CI+branch%3Amaster) |
4 | 5 | [](https://codecov.io/gh/TuringLang/DynamicPPL.jl)
|
| 6 | +[](https://colprac.sciml.ai/) |
| 7 | +[](https://app.bors.tech/repositories/24589) |
5 | 8 |
|
6 | 9 | A domain-specific language and backend for probabilistic programming languages, used by [Turing.jl](https://github.com/TuringLang/Turing.jl).
|
| 10 | + |
| 11 | +## Do you want to contribute? |
| 12 | + |
| 13 | +If you feel you have some relevant skills and are interested in contributing then please do get in touch and open an issue on Github. |
| 14 | + |
| 15 | +### Contributor's Guide |
| 16 | + |
| 17 | +This project follows the [](https://colprac.sciml.ai/), apart from the following slight variation: |
| 18 | + |
| 19 | +- The master branch contains the most recent release at any point in time. All non-breaking changes (bug fixes etc.) are merged directly into master and a new patch version is released immediately. |
| 20 | +- A separate dev branch contains all breaking changes, and is merged into master when a minor version release happens. |
| 21 | + |
| 22 | +For instance, suppose we are currently on version 0.13.5. |
| 23 | + |
| 24 | +- If someone produces a bug fix, it is merged directly into master and bumps the version to 0.13.6. This change is also merged into dev so that it remains up-to-date with master. |
| 25 | +- If someone is working on a new feature that is not breaking (performance-related, fancy new syntax that is backwards-compatible etc.), the same happens. |
| 26 | +- New breaking changes are merged into dev until a release is ready to go, at which point dev is merged into master and version 0.14 is released. |
| 27 | + |
| 28 | +### Bors |
| 29 | + |
| 30 | +This project uses [Bors](https://bors.tech/) for merging PRs. Bors is a Github bot that prevents merge skew / semantic merge conflicts by testing |
| 31 | +the exact integration of pull requests before merging them. |
| 32 | + |
| 33 | +When a PR is good enough for merging and has been approved by at least one reviewer, instead of merging immediately, it is added to the merge queue |
| 34 | +by commenting with `bors r+`. The Bors bot merges the pull request into a staging area, and runs the CI tests. If tests pass, the commit in the staging |
| 35 | +area is copied to the target branch (i.e., usually master). |
| 36 | + |
| 37 | +PRs can be tested by adding a comment with `bors try`. Additional commands can be found in the [Bors documentation](https://bors.tech/documentation/). |
0 commit comments