joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-27 01:36:13 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Site Docs: Update release instructions

Browse source 
Describe how to prepare a release in advance.
This commit is contained in:
David A. Harding 2015-04-10 15:59:19 -04:00
parent 6264930505
commit d620ce61f2
2 changed files with 85 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
Makefile
View file

@ -222,6 +222,8 @@ manual-check-diff-sha256sums:
| sort -k2 | sort -k2
check-for-broken-bitcoin-core-download-links: check-for-broken-bitcoin-core-download-links:
## Ensure that the links from the Download page to the current Bitcoin
## Core binaries are correct
$S grep 'class="dl"' _site/en/download.html \ $S grep 'class="dl"' _site/en/download.html \
| sed 's/.*href="//; s/".*//' \ | sed 's/.*href="//; s/".*//' \
| while read url ; do \ | while read url ; do \

84
README.md
View file

@ -436,7 +436,7 @@ Download links will automatically be set to the defaults using the current
release version number, but if you need to change any download URL, edit release version number, but if you need to change any download URL, edit
the file `_templates/download.html` the file `_templates/download.html`
[Once Travis is enabled] You can then create a pull request to the You can then create a pull request to the
master branch and Travis CI will automatically build it and make sure master branch and Travis CI will automatically build it and make sure
the links you provided return a "200 OK" HTTP header. (The actual files the links you provided return a "200 OK" HTTP header. (The actual files
will not be downloaded to save bandwidth.) Alternatively, you can build will not be downloaded to save bandwidth.) Alternatively, you can build
@ -445,6 +445,88 @@ the site locally with `make all` to run the same quality assurance tests.
The file can be edited later to add any optional information (such as a The file can be edited later to add any optional information (such as a
release date) that you didn't have when you created the file. release date) that you didn't have when you created the file.
#### Preparing a release in advance
It's nice to prepare a release pull request in advance so that the
Bitcoin Core developers can just click "Merge Pull Request" when the new
version is released. Here's the recommended recipe, where `<VERSION>`
is the particular version:
1. Create a new branch named `bitcoin-core-<VERSION>`. You can either
do this locally or in GitHub's web GUI.
2. Follow the instructions in the [Release Notes][] section to create a
new release. You should leave the `optional_date` blank unless you
happen to know the date of the planned release.
3. Push the branch to the https://github.com/bitcoin/bitcoin.org
repository so any contributor can edit it. **Don't** open a pull
request yet.
4. Travis CI will build the site from the branch and then run the tests.
The tests will fail because they expect the release binaries to be
present and you're preparing this release request in advance of them
being uploaded.
5. Open the failed Travis CI log. At the end, it will say something like:
ERROR:
Error: Could not retrieve /bin/bitcoin-core-0.10.1/bitcoin-0.10.1-win64-setup.exe
Error: Could not retrieve /bin/bitcoin-core-0.10.1/bitcoin-0.10.1-win32-setup.exe
[...]
6. Copy the errors from above into a text file and remove everything
except for the URLs so that what's left are lines that look like:
/bin/bitcoin-core-0.10.1/bitcoin-0.10.1-win64-setup.exe
/bin/bitcoin-core-0.10.1/bitcoin-0.10.1-win32-setup.exe
[...]
7. Optional, but nice: sort the lines into alphabetical order.
8. Now open a pull request from the `bitcoin-core-<VERSION>` branch to
the `master` branch. We recommend that you use this title: "Releases:
Add Bitcoin Core &lt;VERSION>".
We recommend that you use the following text with any changes you
think are appropriate. **Note:** read all the way to the end of this
enumerated point before submitting your pull request.
This updates the download links to point to <VERSION> and adds the
<VERSION> release notes to the site. I'll keep it updated throughout
the RC cycle, but it can be merged by anyone with commit access
once <VERSION> final is released (see TODO lists below).
CC: @laanwj
Essential TODO:
* [ ] Make sure the download links work. This is automatically checked as part of the Travis CI build, so trigger a rebuild and, if it passes, this should be safe to merge.
Optional TODO (may be done in commits after merge):
* [ ] Add the actual release date to the YAML header in `_releases/0.10.1.md`
* [ ] Add the magnet URI to the YAML header in `_releases/0.10.1.md` (brief instructions for creating the link are provided as comments in that file)
Expected URLs for the Bitcoin Core binaries:
Underneath the line 'Expected URLs', paste the URLs you retrieved
from Travis CI earlier.
Note that @laanwj is Wladimir J. van der Laan, who is usually
responsible for uploading the Bitcoin Core binaries. If someone
else is responsible for this release, CC them instead. If you don't
know who is responsible, ask in #bitcoin-dev on Freenode.
9. After creating the pull request, use the Labels menu to assign it the
"Releases" label. This is important because it's what the Bitcoin
Core release manager will be looking for.
10. After each new Release Candidate (RC) is released, update the
release notes you created in the `_releases` directory. (But don't
worry about this too much; we can always upload updated release
notes after the release.)
### Alerts ### Alerts
Network alerts should be placed in `_alerts/YYYY-MM-DD-SHORTITLE.html` and adhere to this format: Network alerts should be placed in `_alerts/YYYY-MM-DD-SHORTITLE.html` and adhere to this format: