docs(dev): rename dev docs directory to 'docs'
This commit is contained in:
65
docs/COMMITS.md
Normal file
65
docs/COMMITS.md
Normal file
@@ -0,0 +1,65 @@
|
||||
# Git Commit Guidelines
|
||||
|
||||
We have very precise rules over how our git commit messages can be formatted. This leads to **more
|
||||
readable messages** that are easy to follow when looking through the **project history**. But also,
|
||||
we use the git commit messages to **generate the change log**.
|
||||
|
||||
## Commit Message Format
|
||||
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
|
||||
format that includes a **type**, a **scope** and a **subject**:
|
||||
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
<BLANK LINE>
|
||||
<body>
|
||||
<BLANK LINE>
|
||||
<footer>
|
||||
```
|
||||
|
||||
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
|
||||
to read on github as well as in various git tools.
|
||||
|
||||
## Type
|
||||
Must be one of the following:
|
||||
|
||||
* **feat**: A new feature
|
||||
* **fix**: A bug fix
|
||||
* **docs**: Documentation only changes
|
||||
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
|
||||
semi-colons, etc)
|
||||
* **refactor**: A code change that neither fixes a bug or adds a feature
|
||||
* **perf**: A code change that improves performance
|
||||
* **test**: Adding missing tests
|
||||
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
|
||||
generation
|
||||
|
||||
## Scope
|
||||
The scope should refer to a module in hyper that is being touched. Examples:
|
||||
|
||||
* client
|
||||
* server
|
||||
* http1
|
||||
* http2
|
||||
* ffi
|
||||
* upgrade
|
||||
* examples
|
||||
|
||||
## Subject
|
||||
|
||||
The subject contains succinct description of the change:
|
||||
|
||||
* use the imperative, present tense: "change" not "changed" nor "changes"
|
||||
* don't capitalize first letter
|
||||
* no dot (.) at the end
|
||||
|
||||
## Body
|
||||
|
||||
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes"
|
||||
The body should include the motivation for the change and contrast this with previous behavior.
|
||||
|
||||
## Footer
|
||||
|
||||
The footer should contain any information about **Breaking Changes** and is also the place to
|
||||
reference GitHub issues that this commit **Closes**.
|
||||
|
||||
The last line of commits introducing breaking changes should be in the form `BREAKING CHANGE: <desc>`
|
||||
9
docs/MSRV.md
Normal file
9
docs/MSRV.md
Normal file
@@ -0,0 +1,9 @@
|
||||
# Minimum Support Rust Version (MSRV)
|
||||
|
||||
hyper's current policy is to always support a Rust version at least 6 months
|
||||
old. That is, a compiler version released within the last 6 months can compile
|
||||
hyper. It is possible that an older compiler can work, but that is not
|
||||
guaranteed. We try to increase the MSRV responsibly, only when a significant
|
||||
new feature is needed.
|
||||
|
||||
The current MSRV is: **1.46**.
|
||||
3
docs/README.md
Normal file
3
docs/README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# Developing hyper
|
||||
|
||||
This is a set of documents outline how hyper is developed, how to contribute or get involved, various processes we use, and internal design explanations.
|
||||
Reference in New Issue
Block a user