@@ -38,6 +38,9 @@ we follow in the documentation
38
38
majority of the documentation is generated from python docstrings written using
39
39
NumPy documentation format.
40
40
41
+ The changelogs can be found in docs/changelog/. There is a changelog file for
42
+ each released version of the software.
43
+
41
44
## Tests
42
45
43
46
Simphony uses the [ pytest] ( https://docs.pytest.org/en/latest/ ) testing
@@ -63,9 +66,29 @@ repeatedly until no installations remain) and running the following commands
63
66
python3 setup.py sdist bdist_wheel
64
67
pip install dist/simphony-[VERSION].tar.gz
65
68
```
69
+ ## Contributing
70
+
71
+ All contributions and new features or bug fixes should be worked on in forks
72
+ or branches of the repository. Issues should be opened, and pull requests
73
+ should reference and [ close those issues] ( https://help.github.com/en/articles/closing-issues-using-keywords ) .
74
+ This is good versioning and documentation practice.
66
75
67
76
## Maintainers
68
77
78
+ Remember that all changes are to be integrated through pull requests. Development
79
+ work should be done in branches or forks of the repository. Once implemented
80
+ (and tested on their own), these pull requests should be merged into the
81
+ "master" branch for full testing with the whole program. Each time the package
82
+ is released on PyPI, the package should have a pull request opened to its
83
+ corresponding release branch (release-MAJOR.MINOR.x). The hierarchy is then
84
+ as follows:
85
+
86
+ - release.* (stable branch)
87
+ - master (integration and final testing)
88
+ - feature-name (feature development and bug fixes)
89
+
90
+ Even if you are the lone developer, we follow the methodology [ here] ( https://softwareengineering.stackexchange.com/a/294048 ) .
91
+
69
92
Be sure to update the version number manually before pushing each new version
70
93
to PyPI. Also be sure to amend the changelog. Versions can be pushed to PyPI
71
94
using the command:
0 commit comments