Merge pull request #1074 from jan-cerny/release_readme

Update release tools README

Author: mpreisler

release_tools/README.adoc

@@ -2,31 +2,33 @@
 
 == Prerequisities ==
 
-* The `.env` file.
-  Create `.env` file in this directory (i.e. where the release scripts are).
-  You are supposed to define environment variables that contain sensitive information, s.a. GitHub access tokens.
-  Exact contents of the file are described below.
-
-* Github automation
- * System with `python3.6` or greater, installed https://pypi.python.org/pypi/PyGithub/1.35[PyGithub] module.
- * A Github token - get one on https://github.com/settings/tokens and put it in the `.env` file, so it contains the line `GITHUB_TOKEN='<your token here>'`.
+* System with `python3.6` or greater, installed https://pypi.python.org/pypi/PyGithub/1.35[PyGithub] module.
+* A GitHub token - get one on https://github.com/settings/tokens. Choose `repo` scope.
 
 == Process ==
 
-1. Clone a clean `openscap` repository:
+. Clone a clean `openscap` repository:
 
    git clone https://github.com/OpenSCAP/openscap.git
 
-2. Check out that the information within `versions.sh` is accurate.
+. Create `.env` file
++
+You are supposed to define environment variables that contain sensitive information, s.a. GitHub access tokens.
+Create an `.env` file in the `release_tools` directory (i.e. where the release scripts are).
+Put your GitHub token in the `.env` file, so it contains the following line:
+
+   GITHUB_TOKEN='<your token here>'
+
+. Check out that the information within `versions.sh` is accurate.
 +
-Openscap versions are supposed to have correct values from the previous build (see the step 6), but e.g. the `latest_fedora` and `latest_rhel` may need to be updated if work on a distribution with new version has begun.
+OpenSCAP versions are supposed to have correct values from the previous build (see the step 6), but e.g. the `latest_fedora` and `latest_rhel` may need to be updated if work on a distribution with new version has begun.
 
-3. Run `up_to_compliance_check.sh`.
+. Run `up_to_compliance_check.sh`.
 +
 In the ideal case, the script ends after the ABI compatiblity check finishes.
 Review the check results and act accordingly to them.
 
-4. Run `handle_ltversions.sh`.
+. Run `handle_ltversions.sh`.
 +
 According to the result from the compliance check (and the decision what to do about possible API/ABI changes), you run the script with an argument `bugfix`, `backwards_compatible` or `breaking_change`.
 +
@@ -39,7 +41,7 @@ Use this guideline to decide:
 +
 This changes the libtool library version number so it reflects the API/ABI change.
 
-5. Update the NEWS and make the release commit.
+. Update the NEWS and make the release commit.
 +
 Make sure that everything in the repository is in place, and that the only thing missing is the `NEWS` file and tags.
 Use the `news_template.sh` script to generate a starting point for your `NEWS` file.
@@ -49,7 +51,7 @@ Use it to update the `NEWS` file and commit it.
 +
 The last commit before the release has to have the `openscap-<version>` message (e.g. `openscap-1.2.17`).
 
-6. Run `new-release.sh`.
+. Run `new-release.sh`.
 +
 This will create and push version tags, create new GitHub release and handle milestones swap.
 Finally, it will bump version numbers in `versions.sh` to be ready for the next upstream release.