Skip to content
Snippets Groups Projects
Commit c6bf337c authored by EorlBruder's avatar EorlBruder
Browse files

Integrated changes from code-review and added CONTRIBUTING.md

- removed unnecessary notes.rst
- added hint about the prebuilt binaries
- the publish-pipeline now depends on build-pypi
- added CONTRIBUTING.md with all hints required for building a new version
parent ed4e0758
No related branches found
No related tags found
1 merge request!18Added publish-pipeline
......@@ -92,7 +92,6 @@ publish:
tags:
- docker
dependencies:
- build-linux
- build-windows
- build-pypi
only:
- tags@funkwhale/cli
# Contributing to the Funkwhale-Cli project
This guide needs to be expanded and is currently only documenting things for the changelog-generation.
## Typical workflow for a contribution
0. Fork the project if you did not already or if you do not have access to the main repository
1. Checkout the master branch and pull most recent changes: git checkout master && git pull
2. If working on an issue, assign yourself to the issue. Otherwise, consider open an issue before starting to work on something, especially for new features.
3. Create a dedicated branch for your work 42-awesome-fix. It is good practice to prefix your branch name with the ID of the issue you are solving.
4. Work on your stuff
5. Commit small, atomic changes to make it easier to review your contribution
6. Add a changelog fragment to summarize your changes: echo "Implemented awesome stuff (#42)" > changes/changelog.d/42.feature
7. Push your branch
8. Create your merge request
9. Take a step back and enjoy, we're really grateful you did all of this and took the time to contribute!
## Changelog management
To ensure we have extensive and well-structured changelog, any significant work such as closing an issue must include a changelog fragment. Small changes may include a changelog fragment as well but this is not mandatory. If you're not sure about what to do, do not panic, open your merge request normally and we'll figure everything during the review ;)
Changelog fragments are text files that can contain one or multiple lines that describe the changes occurring in a bunch of commits. Those files reside in `changes/changelog.d`.
### Content
A typical fragment looks like that:
> Fixed broken audio player on Chrome 42 for ogg files (#567)
If the work fixes one or more issues, the issue number should be included at the end of the fragment ((#567) is the issue number in the previous example).
If your work is not related to a specific issue, use the merge request identifier instead, like this:
> Fixed a typo in landing page copy (!342)
### Naming
Fragment files should respect the following naming pattern: `changes/changelog.d/<name>.<category>`. Name can be anything describing your work, or simply the identifier of the issue number you are fixing. Category can be one of:
- `feature`: for new features
- `enhancement`: for enhancements on existing features
- `bugfix`: for bugfixes
- `doc`: for documentation
- `i18n`: for internationalization-related work
- `misc`: for anything else
### Shortcuts
Here is a shortcut you can use/adapt to easily create new fragments from command-line:
```bash
issue="42"
content="Fixed an overflowing issue on small resolutions (#$issue)"
category="bugfix"
echo "$content ($issue)" > changes/changelog.d/$issue.$category
```
You can of course create fragments by hand in your text editor, or from Gitlab's
interface as well.
## Making a release
To make a new 3.4 release:
```bash
# setup
export NEXT_RELEASE=3.4 # replace with the next release number
export PREVIOUS_RELEASE=3.3 # replace with the previous release number
# ensure you have an up-to-date repo
git checkout master
git pull
# compile changelog
towncrier --version $NEXT_RELEASE --yes
# polish changelog
# - update the date
# - look for typos
# - add list of contributors via `python3 scripts/get-contributions-stats.py develop $PREVIOUS_RELEASE`
nano CHANGELOG
# Set the `version` variable to $NEXT_RELEASE
nano setup.cfg
# commit
git add .
git commit -m "Version bump and changelog for $NEXT_RELEASE"
# tag
git tag $NEXT_RELEASE
# publish
git push --tags && git push
```
\ No newline at end of file
Next release notes
==================
.. note::
Those release notes refer to the current development branch and are reset
after each release.
Upgrade via pip.
Upgrade via pip or use our prebuilt binaries for Linux or Windows.
{% for section, _ in sections.items() %}
{% if sections[section] %}
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment