|
1 |
| -Since releasing new versions is currently a somewhat complicated task, the current procedure |
2 |
| -(17.02.2020) will be outlined in this document. |
3 | 1 |
|
4 |
| -All of this has only been tested on Debian 11 (Linux). |
| 2 | +# Release |
5 | 3 |
|
6 |
| -# Prerequirements |
| 4 | +The release process uses `flit` to build the package, `Sphinx` to generate documentation, |
| 5 | +publishes the documentation to an IPFS server (obtaining an IPFS hash), and then links |
| 6 | +the IPFS hash (which varies based on content) to a static IPNS name. |
7 | 7 |
|
8 |
| -## Building and updating the project |
| 8 | +The IPNS name requires a private key, which is controlled by the project owners and not |
| 9 | +available to the public. |
9 | 10 |
|
10 |
| -### The `flit` project manager |
| 11 | +All steps can be completed up through but not including linking the IPFS hash to IPNS. |
11 | 12 |
|
12 |
| -APT line: `sudo apt install python3-pip && sudo pip3 install flit` |
13 |
| -DNF line: `sudo dnf install python3-flit` |
14 | 13 |
|
15 |
| -*Note*: Version `2.0+` of `flit` is required! |
| 14 | +## Pre-Requisites |
16 | 15 |
|
17 |
| -## Building the documentation |
| 16 | +* On Debian |
| 17 | +* Python 3.8+ (or typings will be incomplete) |
18 | 18 |
|
19 |
| -### Sphinx & the `recommonmark` preprocessor |
20 | 19 |
|
21 |
| -Sphinx is the standard documentation framework for Python. Recommonmark is an extension that allows |
22 |
| -Sphinx to process Markdown documentation as if it where reStructuredText. |
| 20 | +## One-Time Setup |
23 | 21 |
|
24 |
| -<!-- APT line: `sudo apt install python3-sphinx python3-recommonmark` --> |
25 |
| -<!--DNF line: `sudo dnf install python3-sphinx python3-recommonmark`--> |
| 22 | +Install the release tools into your virtual environment: |
26 | 23 |
|
27 |
| -At least Sphinx 3.0 with the `sphinx_autodoc_typehints` and reCommonMark 0.5 plugins is required, |
28 |
| -so install them using PIP: |
| 24 | + $ pip install -r tools/release/requirements.txt |
29 | 25 |
|
30 |
| -`pip3 install Sphinx~=3.0 sphinx_autodoc_typehints recommonmark~=0.5.0` |
| 26 | +Source: [tools/release/requirements.txt](tools/release/requirements.txt) |
31 | 27 |
|
32 |
| -For best results Sphinx should be run with Python 3.8+ or typings will be incomplete. |
33 |
| - |
34 |
| -## Hosting Documentation |
35 |
| - |
36 |
| -**Both of the following need to be on the device that will *host the documentation*, not the one |
37 |
| -that will build it**: |
38 | 28 |
|
39 | 29 | ### The Go IPFS daemon
|
40 | 30 |
|
41 | 31 | Yes, we use IPFS to host our documentation. In case you haven't already you can download it here:
|
42 | 32 | https://ipfs.io/docs/install/
|
43 | 33 |
|
| 34 | + |
44 | 35 | ### A dedicated IPNS key for publishing
|
45 | 36 |
|
46 | 37 | For publishing the documentation an IPNS key used only for this task should be
|
47 | 38 | generated if there is no such key already:
|
48 | 39 |
|
49 | 40 | `ipfs key gen --type ed25519 ipfs-http-client`
|
50 | 41 |
|
51 |
| -This key will need to be copied to all other system if the documentation is to |
52 |
| -be published on these as well. |
| 42 | +This key will need to be copied to all other servers hosting the IPNS link. |
| 43 | +Without the private key, other servers can host the IPFS files, but not the IPNS link. |
53 | 44 |
|
54 | 45 | At the time of writing the officially used key is: *12D3KooWEqnTdgqHnkkwarSrJjeMP2ZJiADWLYADaNvUb6SQNyPF*
|
55 | 46 |
|
56 | 47 |
|
57 |
| -# Steps when releasing a new version |
| 48 | +# Steps |
58 | 49 |
|
59 | 50 | ## Update the source code
|
60 | 51 |
|
61 |
| - 1. Make a GIT commit incrementing the version number in `ipfshttpclient/version.py` and completing the currently open `CHANGELOG.md` entry: |
62 |
| - `git commit -m "Release version 0.X.Y" ipfshttpclient/version.py CHANGELOG.md`) |
63 |
| - 2. Tag the GIT commit with the version number using an annotated and signed tag: |
| 52 | + 1. Make a GIT commit |
| 53 | + * Incrementing the version number in `ipfshttpclient/version.py` |
| 54 | + * Completing the currently open `CHANGELOG.md` entry |
| 55 | + |
| 56 | + `git commit -m "Release version 0.X.Y" ipfshttpclient/version.py CHANGELOG.md` |
| 57 | + |
| 58 | + 2. After the change is merged into master, pull master |
| 59 | + |
| 60 | + 3. Tag the GIT commit with the version number using an annotated and signed tag: |
| 61 | + |
64 | 62 | `git tag --sign -m "Release version 0.X.Y" 0.X.Y`
|
65 |
| - 3. Push the new version |
| 63 | + |
| 64 | + 4. Push the new tag |
| 65 | + |
66 | 66 |
|
67 | 67 | ## Upload the new version to PyPI
|
68 | 68 |
|
69 |
| -Run: `flit build && flit publish` |
| 69 | +Run: |
| 70 | + |
| 71 | + $ flit build && flit publish |
70 | 72 |
|
71 | 73 | ## Re-generate and publish the documentation
|
72 | 74 |
|
73 |
| -Run: `docs/publish.py ipfs-http-client` (were `ipfs-http-client` is the IPNS key ID) |
| 75 | +Run: |
| 76 | + |
| 77 | + $ python docs/publish.py ipns-key-id |
74 | 78 |
|
75 | 79 | The command will also print a commandline that may be used to mirror the generated
|
76 | 80 | documentation on systems other then the current one.
|
| 81 | + |
| 82 | +If you don't have the IPNS private key, you can still exercise the documentation |
| 83 | +generation and publish process: |
| 84 | + |
| 85 | + $ python docs/publish.py |
| 86 | + |
| 87 | +If you are publishing to an IPFS server that is remote, and protected by an HTTP reverse proxy |
| 88 | +with TLS and basic authentication, run this instead: |
| 89 | + |
| 90 | + $ IPFS_API_MULTI_ADDR=/dns/yourserver.tld/tcp/5001/https IPFS_API_USERNAME=basicauthuser IPFS_API_PASSWORD=basicauthpassword python publish.py ipns-key-id |
| 91 | + |
0 commit comments