400: Start tracking changelog r=koivunej a=koivunej

Closes #171:

- CONTRIBUTING.md description, algorithm for choosing the CHANGELOG file
- pull_request_template.md
- CHANGELOG.md and unixfs/CHANGELOG.md preparation with `# Next`

Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
This commit is contained in:
bors[bot] 2020-10-06 10:56:56 +00:00 committed by GitHub
commit 05b2a822c2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 47 additions and 0 deletions

View File

@ -9,3 +9,4 @@
- [ ] Each command has a usage example and API specification
- [ ] Rustdoc tests are passing on all code-level comments
- [ ] Differences between Rusts IPFS implementation and the Go or JS implementations are explained
- [ ] Additions to CHANGELOG.md files

6
CHANGELOG.md Normal file
View File

@ -0,0 +1,6 @@
# Next
# 0.2.0
First real release, with big changes and feature improvements. Started tracking
a changelog.

View File

@ -19,11 +19,49 @@ Following these principles in your PRs will greatly increase your chances of a s
1. Keep the patch size minimal
2. Aim for high (but not absolute) code coverage in testing
3. Add a note in the changelog(s)
By keeping the patch size minimal we hope to avoid difficult to review situations where there are lot of lines changed with only a few necessary changes. If you wish to submit a pull request for reorganizing something, please keep all unnecessary changes out.
For example, if you wanted to change the wording of this CONTRIBUTING.md file and dislike the fact that there is no static word wrap used, please push two separate pull requests to first change the wording, and finally to reformat the file.
### Changelogs and their format
We currently maintain two CHANGELOG files:
* [`CHANGELOG.md`](./CHANGELOG.md)
* [`unixfs/CHANGELOG.md`](./unixfs/CHANGELOG.md)
If your PR includes changes to `unixfs/`, include a note in the
`unixfs/CHANGELOG.md`. If your PR includes changes elsewhere, include a note in
the root `CHANGELOG.md`.
The changelog format we've used so far in `unixfs/CHANGELOG.md` is:
```
# {release version}
Short overview.
* Short overview [#PR_NUMBER]
[#PR_NUMBER]: PR_URL
```
If you find yourself writing list of things, just make it multiple items in the
list, like:
```
* Short overview, part of [#PR_NUMBER]
* Another thing, part of [#PR_NUMBER]
[#PR_NUMBER]: PR_URL
```
In the changelog the most recently released version should be first. This
changelog format is more free-form than the more familiar separation of fixes
and features. We will probably later migrate to more detailed changelogs.
## Target Build
Rust IPFS will always target the current _stable_ version of Rust that is released. Our CI/CD tests will reflect this. See [instructions here on how to install the rust toolchain](https://doc.rust-lang.org/book/ch01-01-installation.html).

View File

@ -1,3 +1,5 @@
# Next
# 0.2.0
Minor version bump due to ipfs 0.2.0 release.