mirror of
https://gitea.mueller.network/extern/django-helpdesk.git
synced 2024-11-21 15:33:09 +01:00
Changes per PR review and additional cleanup.
This commit is contained in:
parent
28c09f4fdb
commit
f0e3ef6c8b
@ -31,39 +31,25 @@ Pull Requests
|
|||||||
Please fork the project on GitHub, make your changes, and submit a
|
Please fork the project on GitHub, make your changes, and submit a
|
||||||
pull request against the `main` branch of the `django-helpdesk` repository.
|
pull request against the `main` branch of the `django-helpdesk` repository.
|
||||||
|
|
||||||
Short story:
|
The `main` branch always contains the bleeding edge code that has been reviewed and tested.
|
||||||
|
all features are developed entirely in a separate branch and are only merged to `main` once all tests and maintainer reviews
|
||||||
|
have been passed.
|
||||||
|
|
||||||
* pull requests for `unstable` are for the next major release
|
If for some reason you are forced to stay on an older version and need a patch that may apply to others with the same road
|
||||||
* pull requests for `stable` are for the current release
|
block preventing upgrading to the latest release,
|
||||||
|
then you can check out that versions code using the version tag and push your patch to a branch that we can then tag with a
|
||||||
|
patch release - it will not be merged to the `main` branch.
|
||||||
|
|
||||||
Longer story:
|
We reserve the right to decline a pull request raised against the `main` branch if it does not contain adequate unit tests.
|
||||||
|
|
||||||
In general, our git branching scheme looks like the following.
|
Ideally a PR should be as small as possible to avoid complex and time consuming code reviews.
|
||||||
|
Break up complex new features or code refactoring into manageable chunks and raise sequential PR's.
|
||||||
|
If there are small bugs encountered whilst developing a new feature and they do not have a significant code impact then
|
||||||
|
they can be included in the feature PR.
|
||||||
|
Otherwise each bugfix, feature, code refactoring or functionality change should be in its own PR.
|
||||||
|
|
||||||
* `unstable` always points to development for the next major release,
|
Please provide clear commit messages per file explaining *what*, precisely, has been changed in that file - it aids in
|
||||||
major new features should go here
|
researching behaviour issues down the line.
|
||||||
* `stable` always points to the latest stable release,
|
|
||||||
bugfixes and security patches should go here
|
|
||||||
* current and past major releases can also be found in their own branches:
|
|
||||||
|
|
||||||
* `0.3` is the branch for the 0.3 release and any bugfix releases
|
|
||||||
* `0.2.x` is the branch for the 0.2 release and any bugfix releases
|
|
||||||
* `0.1` is the branch for the legacy code; it is no longer supported
|
|
||||||
|
|
||||||
If you want to submit a specific patch for an older release,
|
|
||||||
you can put your pull request against that branch specifically.
|
|
||||||
However, we don't currently support any older release beyond
|
|
||||||
the latest release (currently 0.3).
|
|
||||||
|
|
||||||
We reserve the right to decline a pull request if it is not for
|
|
||||||
the appropriate branch.
|
|
||||||
|
|
||||||
Wherever possible please break git commits up into small chunks that are
|
|
||||||
specific to a single bit of functionality. For example, a commit should *not*
|
|
||||||
contain both new functionality *and* a bugfix; the new function and the bugfix
|
|
||||||
should be separate commits wherever possible.
|
|
||||||
|
|
||||||
Commit messages should also explain *what*, precisely, has been changed.
|
|
||||||
|
|
||||||
All commits should include appropriate new or updated tests; see the Tests
|
All commits should include appropriate new or updated tests; see the Tests
|
||||||
section below for more details.
|
section below for more details.
|
||||||
@ -103,9 +89,10 @@ Tests
|
|||||||
-----
|
-----
|
||||||
|
|
||||||
There is a CI/CD pipeline implemented using Github actions that covers code formatting, code security and unit tests.
|
There is a CI/CD pipeline implemented using Github actions that covers code formatting, code security and unit tests.
|
||||||
All PR's are required to pass the full test coverage suite before it can be merged to the main branch.
|
All PR's are required to pass the full test coverage suite and a code review by one or more of the maintainers before
|
||||||
|
it can be merged to the main branch.
|
||||||
Currently, test coverage is very low but all new pull requests are required to have appropriate unit tests
|
Currently, test coverage is very low but all new pull requests are required to have appropriate unit tests
|
||||||
to cover the any new or changed functionality which will increase the coverage over time.
|
to cover any new or changed functionality which will increase the coverage over time.
|
||||||
|
|
||||||
|
|
||||||
As a general policy, we will only accept new feature commits if they are
|
As a general policy, we will only accept new feature commits if they are
|
||||||
|
Loading…
Reference in New Issue
Block a user