|
| 1 | +# Contributions |
| 2 | + |
| 3 | +Contributions are welcome in the form of feedback and discussion in issues, |
| 4 | +or pull requests for changes to the code. |
| 5 | + |
| 6 | +Once the implementation of a piece of functionality is considered to be free of |
| 7 | +bugs and properly documented, it can be incorporated into the `main` branch. |
| 8 | + |
| 9 | +## Making a release on GitHub and PyPi |
| 10 | + |
| 11 | +`eeg_positions` is regularly released on |
| 12 | +[GitHub](https://github.com/sappelhoff/eeg_positions/releases) |
| 13 | +and |
| 14 | +[PyPI](https://pypi.org/project/eeg_positions/). |
| 15 | + |
| 16 | +Credentials are currently held by: |
| 17 | + |
| 18 | +- GitHub |
| 19 | + - Admin |
| 20 | + - [@sappelhoff](https://github.com/sappelhoff/) |
| 21 | +- PyPi |
| 22 | + - Owner |
| 23 | + - [@sappelhoff](https://github.com/sappelhoff/) |
| 24 | + |
| 25 | +Releasing on GitHub will automatically trigger a release on PyPi via a GitHub Action |
| 26 | +(The credentials for PyPi are stored as "GitHub Secrets"). |
| 27 | +The release protocol can be briefly described as follows: |
| 28 | + |
| 29 | +1. You will need admin rights for the `eeg_positions` GitHub repository. |
| 30 | +1. Go to your Python environment for `eeg_positions`. |
| 31 | +1. Make sure all tests pass and the docs are built cleanly. |
| 32 | +1. Update the `__version__` variable in `__init__.py`: |
| 33 | + - Remove the `.devN` suffix. |
| 34 | + - If the version preceding the `.devN` suffix is not the version to be |
| 35 | + released, update the version as well according to |
| 36 | + [semantic versioning](https://semver.org/) with its `major.minor.patch` |
| 37 | + style. |
| 38 | +1. If applicable, append new authors to the author metadata in the `CITATION.cff` file. |
| 39 | +1. Update `docs/changes.rst`, renaming the "current" headline to the new |
| 40 | + version |
| 41 | +1. Commit the change and git push to `main` (or make a pull request and merge it). |
| 42 | + Include "REL" in your commit message. |
| 43 | +1. Then, make an annotated tag `git tag -a -m "1.2.3" 1.2.3 upstream/main` (This |
| 44 | + assumes that you have a git remote configured with the name "upstream" and |
| 45 | + pointing to https://github.com/bids-standard/pybv). |
| 46 | + **NOTE: Make sure you have your `main` branch up to date for this step!** |
| 47 | +1. `git push --follow-tags upstream` |
| 48 | +1. Make a [release on GitHub](https://help.github.com/en/articles/creating-releases), |
| 49 | + using the git tag from the previous step (e.g., `1.2.3`). |
| 50 | + Fill the tag name into the "Release title" field, and fill the "Description" field |
| 51 | + as you see fit. |
| 52 | +1. This will trigger a GitHub Action that will build the package and release it to PyPi. |
| 53 | + |
| 54 | +Then the release is done and `main` has to be prepared for development of |
| 55 | +the next release: |
| 56 | + |
| 57 | +1. Update the `__version__` variable in `__init__.py`: |
| 58 | + - Bump up the `major.minor.patch` version according to |
| 59 | + [semantic versioning](https://semver.org/) so that the version will be |
| 60 | + the version that is planned to be released next (e.g., `1.3.0`). |
| 61 | + - Append `.dev0` to the version (e.g., `1.3.0.dev0`). |
| 62 | + - (if you had a version like `1.3.0.dev0` before, release `1.3.0.dev1` instead, etc.) |
| 63 | +1. Add a "Current (unreleased)" headline to `docs/changes.rst`. |
| 64 | +1. Commit the changes and git push to `main` (or make a pull request). |
0 commit comments