Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Releases: blog post & release notes for 0.15.0 #422

Merged
merged 6 commits into from
Sep 14, 2017

Conversation

harding
Copy link
Contributor

@harding harding commented Aug 24, 2017

Preview: http://dg0.dtrt.org/en/2017/09/01/release-0.15.0/

Todo:

  • Set date on blog post to actual release date (change filename and edit YAML metadata)
  • Add sha256sums to bottom of blog post

I'd especially appreciate review of this part about the plans for upcoming default segwit address support in the wallet.

When Travis CI builds a test version of the site, it doesn't have the
/bin directory and so all links to that directory will be reported as
broken (failing the build).  This commit ignores all links to /bin so
the site can build successfully.

- **40% to 50% faster validation of blocks consisting of previously-seen transactions** as the result of repeating fewer validation steps when a previously-verified mempool transaction is later received in a block.

- **Moderate performance gains on some platforms** as the result of using hardware acceleration for some operations, such as support on modern computer processors for single-SHA256 hashing which results in about a 50% improvement each time one of Bitcoin's double-SHA256 hashes needs to be computed. This mainly benefits users of 64-bit Intel and AMD processors produced in 2008 or later.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this is misleading due to the fact that this is disabled-by-default (and in the release binaries). Maybe mention it is just "in testing" or so?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel comfortable saying something is in testing in a post about a release, so in the edit commit I'm about to push, I changed the example to mention the LevelDB CRC acceleration instead. It's less of a cool example IMO, but thanks for not letting me get away with misleading readers.


We decided to take the later option, but we're also not going to wait the normal six months before the next major update. Instead, our next release will be a feature release that generates segwit-compatible addresses by default. This will be made available as soon as it has been written and thoroughly tested.

For those of you interested in technical details, our plan is to use P2SH-wrapped segwit addresses that are compatible with nearly all other wallets on the network. Bech32 native segwit addresses will either be implemented in a subsequent release (assuming no problems arise) or will only be available through expert options for now.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the plan is to support Bech32 native segwit addresses for sending only until the rest of the community updates.


The timing of segwit lock in and activation meant that we had to choose between either delaying the planned release of 0.15.0 and all its features described above or shipping 0.15.0 without a user interface defaulting to segwit.

We decided to take the later option, but we're also not going to wait the normal six months before the next major update. Instead, our next release will be a feature release that generates segwit-compatible addresses by default. This will be made available as soon as it has been written and thoroughly tested.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe "our next feature release will generate..." instead? It is possible (though hopefully unlikely) that we have to do a bugfix release between now and then.

@laanwj
Copy link
Member

laanwj commented Sep 14, 2017

ACK, thanks for writing this

@TheBlueMatt
Copy link
Contributor

TheBlueMatt commented Sep 14, 2017

Looks like this just needs the edate to be set, release notes synced, etc?

@harding
Copy link
Contributor Author

harding commented Sep 14, 2017

Date updated and hashes from https://bitcoincore.org/bin/bitcoin-core-0.15.0/SHA256SUMS.asc added.

@harding
Copy link
Contributor Author

harding commented Sep 14, 2017

Oh, forgot about the release notes. Those have now been updated as well.

@gmaxwell
Copy link

ACK.

@btcdrak btcdrak merged commit 17104fd into bitcoin-core:master Sep 14, 2017
btcdrak added a commit that referenced this pull request Sep 14, 2017
17104fd 0.15.0 release: update release notes (David A. Harding)
e4fde30 0.15.0 release: add hashes for verification (David A. Harding)
a5f3214 0.15.0 release: blog post: use final release date (David A. Harding)
66380fb 0.15.0 release post: edits suggested by BlueMatt (David A. Harding)
2673013 Releases: 0.15.0 blog post + release notes (David A. Harding)
adb4f33 Travis: allow linking to bitcoincore.org/bin (David A. Harding)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants