Polly.Contrib hosts contributions around the Polly project by the community. The project owners have rights on the project repository to merge PRs etc (no review from the Polly team expected or needed, though the team will be happy to take a look if you alert us).
For process, the Polly team recommend that Polly-Contrib projects use Git-Workflow (1; 2) to manage their content:
- Keep the
masterbranch containing only the code as latest released to NuGet (or code imminently to be released).- Sensible exceptions to this may be eg to improve the
ReadMe- the main point is that themasterbranch always represents releasable code.
- Sensible exceptions to this may be eg to improve the
- Carry out development work in feature branches, usually in your own fork of the repo.
- Integrate changes into the
Polly-Contribmasterbranch using PRs.- Using PRs allows other developers who may be interested to comment before code is merged (as mentioned above, it is not expected that the Polly team must do this).
- Using PRs allows developers coming to the project later to see what was added when, and why.
- Avoid contributing code without PRs. Committing without PRs makes it hard for others coming to the project later to review what was added when and why.
- Avoid committing directly to the
masterbranch. Committing interim contributions directly to themasterbranch:- means users cannot review the head of the
masterbranch as a reference for the published nuget packages; - means the
masterbranch is not always in an 'immediately releasable' state - this can be important if an urgent bug fix needs to be released; - creates unnecessarily messy merge-commits and rebasing, when there are multiple contributors.
- means users cannot review the head of the
- Consider using milestones matching release numbers, to label PRs included in and issues closed in a release; see the core Polly project for example.