updated instructions

BUILDING.md

@@ -14,16 +14,16 @@ To test changes the package may be built and uploaded to [test.pypi.org](test.py
 Preferably changes are done on a separate branch.
 
 1.  Make the necessary changes against the `devel` branch
-1.  In `./pyproject.toml` change the versionnumber.
+2.  In `./pyproject.toml` change the versionnumber.
     -  For testing we change the MINOR version to the next **odd** value.
     -  The first PATCH version always starts on x.y.1 and increases by +1 with every new build.
     -  Builds with the same versionnumber can't be uploaded to PyPi, so it's not like we have a choice.
-1.  Run `./mkbld -b`
-1.  Run `./mkbld -t`  *(installation instructions are displayed on the terminal after the upload)*
-1.  Test the changes by installing the test package on a computer near you. *NOTE: You may have to try twice or wait a couple of minutes for the download to become available from PyPi.*
-1.  Rinse and repeat...
-1.  Execute `git commit -a; git push` to commit the changes.
-1.  After succesfull testing create a pull request to merge the changes into the `latest` branch.
+3.  Run `./mkbld -b`
+4.  Run `./mkbld -t`  *(installation instructions are displayed on the terminal after the upload)*
+5.  Test the changes by installing the test package on a computer near you. *NOTE: You may have to try twice or wait a couple of minutes for the download to become available from PyPi.*
+6.  Rinse and repeat...
+7.  Execute `git commit -a; git push` to commit the changes.
+8.  After succesfull testing create a pull request to merge the changes into the `latest` branch.
 
 ## Building the package for distribution
 
@@ -32,24 +32,24 @@ To distribute a new production version the package must be built and uploaded to
 1.  Make the necessary changes...
     -  Merges from a separate branch are considered MINOR changes.
     -  Fixes etc. may be committed directly to the `latest` branch as a new PATCH version.
-1.  In `./pyproject.toml` change the versionnumber.
+2.  In `./pyproject.toml` change the versionnumber.
     -  For merges we change the MINOR version to the next **even** value.
     -  The first PATCH version always starts on x.y.1 and increases by +1 with every new build.
     -  Builds with the same versionnumber can't be uploaded to PyPi, so it's not like we have a choice.
-1.  Run `./mkbld -b`
-1.  Run `./mkbld -d`  *(installation instructions are displayed on the terminal after the upload)*
-1.  Test the changes by installing the distribution package on a computer near you. *NOTE: You may have to try twice or wait a couple of minutes for the download to become available from PyPi.*
-1.  Rinse and repeat...
-1.  Execute `git commit -a; git push` to commit the changes.
-1.  After succesfull testing of the distribution package create a new tag on the `latest` branch.
+3.  Run `./mkbld -b`
+4.  Run `./mkbld -d`  *(installation instructions are displayed on the terminal after the upload)*
+5.  Test the changes by installing the distribution package on a computer near you. *NOTE: You may have to try twice or wait a couple of minutes for the download to become available from PyPi.*
+6.  Rinse and repeat...
+7.  Execute `git commit -a; git push` to commit the changes.
+8.  After succesfull testing of the distribution package create a new tag on the `latest` branch.
 
 ## Support for a (new) version of BlueZ
 
-By default versions 5.47, 5.50, 5.60, 5.66 and 5.68 of the BlueZ stack are supported. To add support for a new version of
+By default versions 5.47, 5.50, 5.60, 5.66, 5.68, 5.70 of the BlueZ stack are supported. To add support for a new version of
 the stack and compile the `bluepy3-helper.c` against it the following must be changed:
 
 1.  Create a new branch for testing as detailed above.
-1.  Create a copy of the `./bluepy3/config.<version>.h`; where *\<version\>* is the version tagname of the [bluez stack](https://github.com/bluez/bluez) to be used.
+2.  Create a copy of the `./bluepy3/config.<version>.h`; where *\<version\>* is the version tagname of the [bluez stack](https://github.com/bluez/bluez) to be used.
     -  In this new file change the `#define`s to match the versionnumber
         ```
         /* Define to the full name and version of this package. */
@@ -61,8 +61,6 @@ the stack and compile the `bluepy3-helper.c` against it the following must be ch
         /* Version number of package */
         #define VERSION "5.68"
         ```
-1.  In the `Makefile` change the first line to match te desired versionnumber.
-    ```
-    BLUEZ_VERSION=5.68
-    ```
-1.  Complete the building instructions for testing as described above.
+3.  Complete the building instructions for testing as described above.
+4.  Install on the test system and use `helpermaker --build <version>` to confirm that it will compile.
+5.  Make adjustments as needed to get the new version to compile.