Bump alacritty_terminal version

This change bumps the version of the `alacritty_terminal` crate to force
it out of sync with the Alacritty application. Since it is a library
that will be published on crates.io, it should be following semver
rather than our binary's release version.

While it would be possible to just keep it at 0.5.0, explicitly
disconnecting it from the Alacritty version should give it a clean
starting-off point and prevent unnecessary confusion. Bumping it to
0.10.0 instead of something like 0.6.0 should allow for a nice gap
between the different versions without being too arbitrary. Changing the
version to 0.1.0 is not an option since decreasing semver version would
likely cause a lot of problems.

While it would be possible to further separate the Alacritty terminal
library from the Alacritty terminal emulator, by renaming it from
`alacritty_terminal` to something different, I don't think that is
necessary or a good idea at the moment. Even though the
`alacritty_terminal` library *can* be used for other terminals, its
primary goal is still to support the Alacritty terminal emulator and I
don't see that changing. So making that clear in its name seems like a
good idea. Since there is no plan to maintain this library separately
from Alacritty, but to keep both tied together, the naming should
reflect this.

1 files changed, 13 insertions, 3 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 6e426513..d87a23e7 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -45,6 +45,9 @@ issues.
 Please note that the minimum supported version of Alacritty is Rust 1.41.0. All patches are expected
 to work with the minimum supported version.
 
+Since `alacritty_terminal`'s version always tracks the next release, make sure that the version is
+bumped according to semver when necessary.
+
 ### Testing
 
 To make sure no regressions were introduced, all tests should be run before sending a pull request.
@@ -128,10 +131,11 @@ The exact steps for an exemplary `0.2.0` release might look like this:
      major issues are found in the release candidates
   9. In the branch, the version is bumped to `0.2.0`
  10. The new commit in the branch is tagged as `v0.2.0`
- 11. A GitHub release is created for the `v0.2.0` tag
- 12. The changelog since the last stable release (**not** RC) is added to the GitHub release
+ 11. The new version is published to crates.io
+ 12. A GitHub release is created for the `v0.2.0` tag
+ 13. The changelog since the last stable release (**not** RC) is added to the GitHub release
      description
- 13. The `-dev` is stripped from the `0.2.0-dev` changelog entries on master
+ 14. The `-dev` is stripped from the `0.2.0-dev` changelog entries on master
 
 On master and with new planned releases, only the minor version is bumped. This makes it possible to
 create bug fix releases by incrementing the patch version of a previous minor release, without
@@ -145,6 +149,12 @@ The exact steps for an exemplary `0.2.3` release might look like this:
  6. Follow Steps 5-12 of the regular release's example
  7. The release's changelog is ported back to master, removing fixes from the `0.2.3` release
 
+The `alacritty_terminal` crate is released in synchronization with `alacritty`, keeping the `-dev`
+and `-rcX` version suffix identical across the two crates. As soon as the new Alacritty stable
+release is made, releases are tagged as `alacritty_terminal_vX.Y.Z` and pushed to crates.io. During
+a release, only the patch version is bumped on master, since there haven't been any changes since
+the last release yet.
+
 # Contact
 
 If there are any outstanding questions about contributing to Alacritty, they can be asked on the