An open API service indexing awesome lists of open source software.

https://github.com/pyeve/maintainers

Guidelines for maintainers of pyeve-related repositories and projects
https://github.com/pyeve/maintainers

Last synced: 11 months ago
JSON representation

Guidelines for maintainers of pyeve-related repositories and projects

Awesome Lists containing this project

README

          

# Git-related guidelines

The following guidelines are a description of the workflows that are mandatory
for the maintenance of any git repository of the `pyeve` organization.

Though it is still a *draft*.

## General considerations

- The `git` history shall preserve as much information as possible, e.g. about
merge events, that can be explored with
`git log --graph --decorate --all --oneline`
- "Now is better than never." is imperative regarding changelogs and authors
lists.
- The changelog shall be wrapped at 80 characters for readability on common
devices.

## Variable names for the examples

The following placeholders are used below:

- `` is the numerical identifier of a pull request
- `` is the name of the authorative remote repository on `github.com`
- usually `upstream` or `origin`

## Merging pull requests into the master branch

1. There is a consent among the reviewers to proceed.
- One shall of course review own proposed changes, but obviously one's voice
doesn't count in the review process.
2. Make sure to work on the up-to-date `master` branch:
`git checkout master && git pull master`
3. Fetch the desired pull request's changes:
`git fetch pull//head:pull_`
4. Check it out:
`git checkout pull_`
5. Align it with the state of the `master` branch:
`git rebase master`
6. Check that there is a descriptive note including references to relevant
issues in the "Unreleased" section of the changelog and that all involved
contributors are mentioned in the authors list. Mind to commit adjustments.
7. Push the current state to trigger jobs on the CI:
`git push pull_`.
Depending on the changes and available interpreters, local tests may be
sufficient or even better.
8. Actually merge and publish the changes:
`git checkout master && git merge --no-ff pull_ && git push master`
9. If applicable, proceed with "Backporting fixes" below. If so, you may repeat
this flow with other pull requests before.

## Publishing a major or minor release

1. All related issues and pull requests in the issue tracker are closed.
2. Make sure to work on the up-to-date `master` branch:
`git checkout master && git pull master`
3. Update the "Unreleased" section in the changelog and the version in
`setup.py`.
4. Commit and publish these changes on `github.com`:
`git commit -a -m "Bumps to version ." && git push master`
5. Create a git tag and publish it:
`git tag . && git push .`
6. Publish the new version on the PyPI:
`python setup.py sdist`
7. Add a new "Unreleased" section in the changelog, commit and publish this on `master`.
8. Create a new branch for the minor release and publish it:
`git checkout -b ..x && git push --set-upstream ..x`

## Backporting fixes

1. You have an ordered list of commit hashes (``) that need to be
backported for a minor version.
2. Work on an up-to-date branch for that minor version:
`git checkout ..x && git pull ..x`
3. Apply the commits:
`git cherry-pick ...`
4. Run tests and update the changelog.
5. Publish the backported changes:
`git push ..x`

## Publishing a micro / bug fix release

1. All related issues and pull requests in the issue tracker are closed.
2. Work on an up-to-date branch for the related minor version:
`git checkout ..x && git pull ..x`
3. Update the "Unreleased" section in the changelog and the version in
`setup.py`.
4. Commit and publish these changes on `github.com`:
`git commit -a -m "Bumps to version ." && git push ..x`
5. Create a git tag and publish it:
`git tag .. && git push ..`
6. Publish the new version on the PyPI:
`python setup.py sdist`
7. Copy the changelog section of this release to the changelog in the `master`
branch, commit and publish the result to ``.