|
1 |
| -Contributing |
2 |
| -============ |
| 1 | +Development and Contributing |
| 2 | +============================ |
3 | 3 |
|
4 | 4 | The development of python-for-android is managed by the Kivy team `via
|
5 | 5 | Github <https://github.com/kivy/python-for-android>`_.
|
6 | 6 |
|
7 | 7 | Issues and pull requests are welcome via the integrated `issue tracker
|
8 | 8 | <https://github.com/kivy/python-for-android/issues>`_.
|
| 9 | + |
| 10 | +Read on for more information about how we manage development and |
| 11 | +releases, but don't worry about the details! Pull requests are welcome |
| 12 | +and we'll deal with the rest. |
| 13 | + |
| 14 | +Development model |
| 15 | +----------------- |
| 16 | + |
| 17 | +python-for-android is developed using the following model:: |
| 18 | + |
| 19 | +- The ``master`` branch always represents the latest stable release. |
| 20 | +- The ``develop`` branch is the most up to date with new contributions. |
| 21 | +- Releases happen periodically, and consist of merging the current ``develop`` branch into ``master``. |
| 22 | + |
| 23 | +For reference, this is based on a `Git flow |
| 24 | +<https://nvie.com/posts/a-successful-git-branching-model/>`__ model, |
| 25 | +although we don't follow this religiously. |
| 26 | + |
| 27 | +Versioning |
| 28 | +---------- |
| 29 | + |
| 30 | +python-for-android releases currently use `calendar versioning |
| 31 | +<https://calver.org/>`__. Release numbers are of the form |
| 32 | +YYYY.MM.DD. We aim to create a new release every four weeks, but more |
| 33 | +frequent releases are also possible. |
| 34 | + |
| 35 | +We use calendar versioning because in practice, changes in |
| 36 | +python-for-android are often driven by updates or adjustments in the |
| 37 | +Android build tools. It's usually best for users to be working from |
| 38 | +the latest release. We try to maintain backwards compatibility even |
| 39 | +while internals are changing. |
| 40 | + |
| 41 | + |
| 42 | +Creating a new release |
| 43 | +---------------------- |
| 44 | + |
| 45 | +New releases follow these steps: |
| 46 | + |
| 47 | +- Create a new branch ``release/YYYY.MM.DD`` based on the ``develop`` branch. |
| 48 | + - ``git checkout -b release/YYYY.MM.DD develop`` |
| 49 | +- Create a Github pull request to merge ``release/YYYY.MM.DD`` into ``master``. |
| 50 | +- Complete all steps in the `release checklist <release_checklist_>`_, |
| 51 | + and document this in the pull request (copy the checklist into the PR text) |
| 52 | + |
| 53 | +At this point, wait for reviewer approval and conclude any discussion that arises. To complete the release: |
| 54 | + |
| 55 | +- Merge the release branch to the ``master`` branch. |
| 56 | +- Also merge the release branch to the ``develop`` branch. |
| 57 | +- Tag the release commit in ``master``. Include a short summary of the changes. |
| 58 | +- Create the release distributions: ``python3 setup.py sdist`` |
| 59 | +- Upload the release to pypi: ``python3 -m twine upload``. |
| 60 | +- Upload the release ``.tar.gz`` to the Github tag. |
| 61 | + |
| 62 | +.. _release_checklist: |
| 63 | + |
| 64 | +Release checklist |
| 65 | +~~~~~~~~~~~~~~~~~ |
| 66 | + |
| 67 | +- [ ] Check that the [build is passing](https://travis-ci.org/kivy/python-for-android) |
| 68 | +- [ ] Run the tests locally via `tox`: this performs some long-running tests that are skipped on Travis. |
| 69 | +- [ ] Build and run the [on_device_unit_tests](https://github.com/kivy/python-for-android/tree/master/testapps/on_device_unit_tests) app using buildozer. Check that they all pass. |
| 70 | +- [ ] Build and run the following [testapps](https://github.com/kivy/python-for-android/tree/master/testapps) for arch `armeabi-v7a` and `arm64-v8a`: |
| 71 | + - [ ] `python3 setup_testapp_python3_sqlite_openssl.py apk` |
| 72 | + - [ ] `python3 setup_testapp_python2.py apk` |
| 73 | +- [ ] Check that the version number is correct |
0 commit comments