mirror of
https://github.com/alacritty/alacritty.git
synced 2024-11-18 13:55:23 -05:00
parent
fb046091f6
commit
047719bcd2
3 changed files with 81 additions and 18 deletions
2
.github/pull_request_template.md
vendored
2
.github/pull_request_template.md
vendored
|
@ -1,3 +1,3 @@
|
|||
Please make sure to document all user-facing changes in the `CANGELOG.md` file.
|
||||
Please make sure to document all user-facing changes in the `CHANGELOG.md` file.
|
||||
|
||||
Draft PRs are always welcome, though unless otherwise requested PRs will not be reviewed until all required and optional CI steps are successful and they have left the draft stage.
|
||||
|
|
|
@ -22,7 +22,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|||
- Direct escape input on Windows using alt
|
||||
- Incorrect window size on X11 when waking up from suspend
|
||||
|
||||
## 0.4.0-dev
|
||||
## 0.4.0
|
||||
|
||||
### Packaging
|
||||
|
||||
|
|
|
@ -11,56 +11,119 @@ Table of Contents:
|
|||
2. [Performance](#performance)
|
||||
3. [Documentation](#documentation)
|
||||
4. [Style](#style)
|
||||
4. [Contact](#contact)
|
||||
4. [Release Process](#release-process)
|
||||
5. [Contact](#contact)
|
||||
|
||||
## Feature Requests
|
||||
|
||||
Feature requests should be reported in the [Alacritty issue tracker](https://github.com/jwilm/alacritty/issues). To reduce the number of duplicates, please make sure to check the existing [enhancement](https://github.com/jwilm/alacritty/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aenhancement) and [missing feature](https://github.com/jwilm/alacritty/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3A%22B+-+missing+feature%22) issues.
|
||||
Feature requests should be reported in the
|
||||
[Alacritty issue tracker](https://github.com/jwilm/alacritty/issues). To reduce the number of
|
||||
duplicates, please make sure to check the existing
|
||||
[enhancement](https://github.com/jwilm/alacritty/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aenhancement)
|
||||
and
|
||||
[missing feature](https://github.com/jwilm/alacritty/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3A%22B+-+missing+feature%22)
|
||||
issues.
|
||||
|
||||
## Bug Reports
|
||||
|
||||
Bug reports should be reported in the [Alacritty issue tracker](https://github.com/jwilm/alacritty/issues).
|
||||
Bug reports should be reported in the
|
||||
[Alacritty issue tracker](https://github.com/jwilm/alacritty/issues).
|
||||
|
||||
If a bug was not present in a previous version of Alacritty, providing the exact commit which introduced the regression helps out a lot.
|
||||
If a bug was not present in a previous version of Alacritty, providing the exact commit which
|
||||
introduced the regression helps out a lot.
|
||||
|
||||
## Patches / Pull Requests
|
||||
|
||||
All patches have to be sent on Github as [pull requests](https://github.com/jwilm/alacritty/pulls).
|
||||
|
||||
If you are looking for a place to start contributing to Alacritty, take a look at the [help wanted](https://github.com/jwilm/alacritty/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) and [easy](https://github.com/jwilm/alacritty/issues?q=is%3Aopen+is%3Aissue+label%3A%22D+-+easy%22) issues.
|
||||
If you are looking for a place to start contributing to Alacritty, take a look at the
|
||||
[help wanted](https://github.com/jwilm/alacritty/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
|
||||
and
|
||||
[easy](https://github.com/jwilm/alacritty/issues?q=is%3Aopen+is%3Aissue+label%3A%22D+-+easy%22)
|
||||
issues.
|
||||
|
||||
Please note that the minimum supported version of Alacritty is Rust 1.36.0. All patches are expected to work with the minimum supported version.
|
||||
Please note that the minimum supported version of Alacritty is Rust 1.36.0. All patches are expected
|
||||
to work with the minimum supported version.
|
||||
|
||||
### Testing
|
||||
|
||||
To make sure no regressions were introduced, all tests should be run before sending a pull request. The following command can be run to test Alacritty:
|
||||
To make sure no regressions were introduced, all tests should be run before sending a pull request.
|
||||
The following command can be run to test Alacritty:
|
||||
|
||||
```
|
||||
cargo test
|
||||
```
|
||||
|
||||
Additionally if there's any functionality included which would lend itself to additional testing, new tests should be added. These can either be in the form of Rust tests using the `#[test]` annotation, or Alacritty's ref tests.
|
||||
Additionally if there's any functionality included which would lend itself to additional testing,
|
||||
new tests should be added. These can either be in the form of Rust tests using the `#[test]`
|
||||
annotation, or Alacritty's ref tests.
|
||||
|
||||
To record a new ref test, a release version of the patched binary should be created and run with the `--ref-test` flag. After closing the Alacritty window, or killing it (`exit` and `^D` do not work), some new files should have been generated in the working directory. Those can then be copied to the `./tests/ref/NEW_TEST_NAME` directory and the test can be enabled by editing the `ref_tests!` macro in the `./tests/ref.rs` file. When fixing a bug, it should be checked that the ref test does not complete correctly with the unpatched version, to make sure the test case is covered properly.
|
||||
To record a new ref test, a release version of the patched binary should be created and run with the
|
||||
`--ref-test` flag. After closing the Alacritty window, or killing it (`exit` and `^D` do not work),
|
||||
some new files should have been generated in the working directory. Those can then be copied to the
|
||||
`./tests/ref/NEW_TEST_NAME` directory and the test can be enabled by editing the `ref_tests!` macro
|
||||
in the `./tests/ref.rs` file. When fixing a bug, it should be checked that the ref test does not
|
||||
complete correctly with the unpatched version, to make sure the test case is covered properly.
|
||||
|
||||
### Performance
|
||||
|
||||
Alacritty mainly uses the [vtebench](https://github.com/jwilm/vtebench) tool for testing Alacritty's performance. Any change which could have an impact on Alacritty's performance, should be tested with it to prevent potential regressions.
|
||||
Alacritty mainly uses the [vtebench](https://github.com/jwilm/vtebench) tool for testing Alacritty's
|
||||
performance. Any change which could have an impact on Alacritty's performance, should be tested with
|
||||
it to prevent potential regressions.
|
||||
|
||||
### Documentation
|
||||
|
||||
Code should be documented where appropriate. The existing code can be used as a guidance here and the general `rustfmt` rules can be followed for formatting.
|
||||
Code should be documented where appropriate. The existing code can be used as a guidance here and
|
||||
the general `rustfmt` rules can be followed for formatting.
|
||||
|
||||
If any change has been made to the `config.rs` file, these changes should also be documented in the example configuration file `alacritty.yml`.
|
||||
If any change has been made to the `config.rs` file, these changes should also be documented in the
|
||||
example configuration file `alacritty.yml`.
|
||||
|
||||
Changes compared to the latest Alacritty release which have a direct effect on the user (opposed to things like code refactorings or documentation/tests) additionally need to be documented in the `CHANGELOG.md`. The existing entries should be used as a style guideline. The change log should be used to document changes from a user-perspective, instead of explaining the technical background (like commit messages). More information about Alacritty's change log format can be found [here](https://keepachangelog.com).
|
||||
Changes compared to the latest Alacritty release which have a direct effect on the user (opposed to
|
||||
things like code refactorings or documentation/tests) additionally need to be documented in the
|
||||
`CHANGELOG.md`. The existing entries should be used as a style guideline. The change log should be
|
||||
used to document changes from a user-perspective, instead of explaining the technical background
|
||||
(like commit messages). More information about Alacritty's change log format can be found
|
||||
[here](https://keepachangelog.com).
|
||||
|
||||
### Style
|
||||
|
||||
All Alacritty changes are automatically verified by CI to conform to its rustfmt guidelines. If a CI build is failing because of formatting issues, you can install rustfmt using `rustup component add rustfmt` and then format all code using `cargo fmt`.
|
||||
All Alacritty changes are automatically verified by CI to conform to its rustfmt guidelines. If a CI
|
||||
build is failing because of formatting issues, you can install rustfmt using `rustup component add
|
||||
rustfmt` and then format all code using `cargo fmt`.
|
||||
|
||||
# Release Process
|
||||
|
||||
Alacritty's release process aims to provide stable and well tested releases without having to hold
|
||||
back new features during the testing period.
|
||||
|
||||
To achieve these goals, a new branch is created for every new release. Both the release candidates
|
||||
and the final version are only comitted and tagged in this branch. The master branch only tracks
|
||||
development versions, allowing us to keep the branches completely separate without merging releases
|
||||
back into master.
|
||||
|
||||
The exact steps for an exemplary `1.2.3` release might look like this:
|
||||
1. Initially, the version on the latest master is `1.2.3-dev`
|
||||
2. A new `v1.2.3` branch is created for the release
|
||||
3. On master, the version is bumped to `1.2.4-dev`
|
||||
and the `-dev` is stripped from previous change log entries
|
||||
4. In the branch, the version is bumped to `1.2.3-rc1`
|
||||
5. The new commit in the branch is tagged as `v1.2.3-rc1`
|
||||
6. A GitHub release is created for the `v1.2.3-rc1` tag
|
||||
7. The changelog since the last release (stable or RC)
|
||||
is added to the GitHub release description
|
||||
8. Bug fixes are cherry-picked from master into the branch and steps 4-7
|
||||
are repeated until no major issues are found in the release candidates
|
||||
9. In the branch, the version is bumped to `1.2.3`
|
||||
10. The new commit in the branch is tagged as `v1.2.3`
|
||||
11. A GitHub release is created for the `v1.2.3` tag
|
||||
12. The changelog since the last stable release (**not** RC)
|
||||
is added to the GitHub release description
|
||||
|
||||
# Contact
|
||||
|
||||
If there are any outstanding questions about contributing to Alacritty, they can be asked on the [Alacritty issue tracker](https://github.com/jwilm/alacritty/issues).
|
||||
If there are any outstanding questions about contributing to Alacritty, they can be asked on the
|
||||
[Alacritty issue tracker](https://github.com/jwilm/alacritty/issues).
|
||||
|
||||
As a more immediate and direct form of communication, the Alacritty IRC channel (`#alacritty` on Freenode) can be used to contact many of the Alacritty contributors.
|
||||
As a more immediate and direct form of communication, the Alacritty IRC channel (`#alacritty` on
|
||||
Freenode) can be used to contact many of the Alacritty contributors.
|
||||
|
|
Loading…
Reference in a new issue