Here we describe the development process overview. It’s in F.A.Q. format to make it simple.
Since version 1.2 we try to make master
in a production-ready state. It
does NOT mean it is production ready, but it SHOULD be. In example, tests at
master
should always pass. Actually, whole tox suite should pass. And it’s
test coverage should be at 100% level.
devel
branch, on the other hand, can break. It shouldn’t but it is
acceptable. As a user, you should NEVER use non-master branches at production.
All the changes are pushed from devel
to master
before next release. It
might happen more frequently.
Just go to https://github.com/lukaszb/django-guardian/issues and create new one.
It’s simple! If you want to fix a bug, extend documentation or whatever you think is appropriate for the project and involves changes, just fork the project at github (https://github.com/lukaszb/django-guardian), create a separate branch, hack on it, publish changes at your fork and create a pull request.
Here is a quick how to:
Fork a project: https://github.com/lukaszb/django-guardian/fork
Checkout project to your local machine:
$ git clone git@github.com:YOUR_NAME/django-guardian.git
Create a new branch with name describing change you are going to work on:
$ git checkout -b bugfix/support-for-custom-model
Perform changes at newly created branch. Remember to include tests (if this
is code related change) and run test suite. See running tests documentation. Also, remember to add yourself to the AUTHORS
file.
(Optional) Squash commits. If you have multiple commits and it doesn’t make much sense to have them separated (and it usually makes little sense), please consider merging all changes into single commit. Please see https://help.github.com/articles/interactive-rebase if you need help with that.
Publish changes:
$ git push origin YOUR_BRANCH_NAME
We usually put an explonation while we close issue or PR. It might be for various reasons, i.e. there were no reply for over a month after our last comment, there were no tests for the changes etc.