Add prettier to the pre-commit configuration

Also apply prettier

1 files changed, 29 insertions, 30 deletions

diff --git a/doc/release.md b/doc/release.md
index ed4346713..994a4f2b0 100644
--- a/doc/release.md
+++ b/doc/release.md
@@ -1,17 +1,16 @@
 # Releasing a pylint version
 
-So, you want to release the ``X.Y.Z`` version of pylint ?
+So, you want to release the `X.Y.Z` version of pylint ?
 
 ## Process
 
-1. Preparation
-   0. Run the acceptance tests to see if everything is alright with this release.
-      We don't run them on CI: ``pytest -m acceptance``
+1. Preparation 0. Run the acceptance tests to see if everything is alright with this
+   release. We don't run them on CI: `pytest -m acceptance`
    1. Check if the dependencies of the package are correct
-   2. Update ``__version__`` in ``pylint/__pkginfo__.py``, ``dev_version`` should be ``None`` when you tag,
-      except if it's an alpha release.
+   2. Update `__version__` in `pylint/__pkginfo__.py`, `dev_version` should be `None`
+      when you tag, except if it's an alpha release.
    3. Put the version numbers, and the release date into the changelog
-   4. Put the release date into the ``What's new`` section.
+   4. Put the release date into the `What's new` section.
    5. Generate the new copyright notices for this release:
 
 ```bash
@@ -22,16 +21,16 @@ git --aliases=.copyrite_aliases . --jobs=8
 # automatically
 ```
 
-   6. Submit your changes in a merge request.
+6. Submit your changes in a merge request.
 
-2. Make sure the tests are passing on Travis/GithubActions:
+7. Make sure the tests are passing on Travis/GithubActions:
    https://travis-ci.org/PyCQA/pylint/
 
-3. Do the actual release by tagging the master with ``pylint-X.Y.Z`` (ie  ``pylint-1.6.12``
-   for example). Travis should deal with the release process once the tag is pushed
-   with `git push origin --tags`
+8. Do the actual release by tagging the master with `pylint-X.Y.Z` (ie `pylint-1.6.12`
+   for example). Travis should deal with the release process once the tag is pushed with
+   `git push origin --tags`
 
-4. Go to github, click on "Releases" then on the ``pylint-X.Y.Z`` tag, choose edit tag,
+9. Go to github, click on "Releases" then on the `pylint-X.Y.Z` tag, choose edit tag,
    and copy past the changelog in the description.
 
 ## Manual Release
@@ -49,16 +48,16 @@ twine upload dist/*
 
 ### New branch to create for major releases
 
-The master branch will have all the new features for the ``X.Y+1`` version
+The master branch will have all the new features for the `X.Y+1` version
 
-If you're doing a major release, you need to create the ``X.Y`` branch
-where we will cherry-pick bugs to release the ``X.Y.Z+1`` minor versions
+If you're doing a major release, you need to create the `X.Y` branch where we will
+cherry-pick bugs to release the `X.Y.Z+1` minor versions
 
 ### Merge tags in master for minor releases
 
-Merge the tag ``X.Y.Z`` in the main branch by doing a history only merge. It's done
-in order to signal that this is an official release tag, and for ``pre-commit autoupdate``
-to works.
+Merge the tag `X.Y.Z` in the main branch by doing a history only merge. It's done in
+order to signal that this is an official release tag, and for `pre-commit autoupdate` to
+works.
 
 ```bash
 git checkout master
@@ -68,26 +67,26 @@ git push
 
 ### Milestone handling
 
-We move issue that were not done in the next milestone and block release only
-if it's an issue labelled as blocker.
+We move issue that were not done in the next milestone and block release only if it's an
+issue labelled as blocker.
 
 ### Files to update after releases
 
 #### Changelog
 
-* Create a new section, with the name of the release ``X.Y.Z+1`` on the ``X.Y`` branch.
-* If it's a major release, also create a new section for ``X.Y+1.0`` on the master branch
+- Create a new section, with the name of the release `X.Y.Z+1` on the `X.Y` branch.
+- If it's a major release, also create a new section for `X.Y+1.0` on the master branch
 
-You need to add the estimated date when it is going to be published. If
-no date can be known at that time, we should use ``Undefined``.
+You need to add the estimated date when it is going to be published. If no date can be
+known at that time, we should use `Undefined`.
 
 #### Whatsnew
 
-If it's a major release, create a new ``What's new in Pylint X.Y+1`` document
-Take a look at the examples from ``doc/whatsnew``.
+If it's a major release, create a new `What's new in Pylint X.Y+1` document Take a look
+at the examples from `doc/whatsnew`.
 
 ### Versions
 
-Update ``__version__`` to ``X.Y+1.0`` in ``pylint/__pkginfo__.py`` for ``master`` and to
-``X.Y.Z+1`` for the ``X.Y`` branch. ``dev_version`` should also be back to an
-integer after the tag.
+Update `__version__` to `X.Y+1.0` in `pylint/__pkginfo__.py` for `master` and to
+`X.Y.Z+1` for the `X.Y` branch. `dev_version` should also be back to an integer after
+the tag.