Release notes for v0.1.0-alpha.24

[carver]

This is the long-running PR for release notes to be included in the next release.

Community contributors are welcome to comment below with your notes, or open a PR to merge into this branch.

Coders with write access are welcome to add commits on top. Please don't force push, though: it would be sad to accidentally blow away someone else's notes.

[carver]

Thoughts on grouping notes by Feature, Bugfix, Performance, etc?

[cburgdorf]

Oh yeah, totally. Let me fix it right away.

[carver]

Yikes, looks like master is broken!

[cburgdorf]

Yikes, looks like master is broken!

Wait, what? Last commit on master is 0838ffb which went through CI just fine?

[carver]

Yikes, looks like master is broken!

Wait, what? Last commit on master is 0838ffb which went through CI just fine?

That commit is 24 days ago, the failing commit 14fab95 is from 3 days ago.

The breakage is presumably from pulling in a dependency that was released sometime between 3-24 days ago.

[cburgdorf]

But that commit isn't on master. It's in the release-notes branch, which I assume will be all squashed, rebased and picked into one commit onto master at the point where we cut a new release, no?

[carver]

But that commit isn't on master. It's in the release-notes branch, which I assume will be all squashed, rebased and picked into one commit onto master at the point where we cut a new release, no?

Why would a squash/rebase affect any of those lint failures?

[cburgdorf]

Why would a squash/rebase affect any of those lint failures?

Because those do not exist on latest master (e.g. here's a PR that is just several hours old, builds on latest master and is green #557). So, once you rebase this branch on latest master, the linting issues should just magically vaporize (hint: because latest master is on a newer mypy version etc).

Or to put it another way, this PR, the release-notes branch does only modify the trinity.rst file and we should feel free to ignore any CI fails in this branch that aren't directly related to changes to the trinity.rst file.

When the time comes, we'll squash all changes into one commit, rebase on top of latest master and all issues should magically disappear under the assumption that master is passing which seems to be the case.

The alternative would be rebase this branch now and then force push it but the issue description says this should be avoided.

Please don't force push, though: it would be sad to accidentally blow away someone else's notes.

[carver]

Because those do not exist on latest master (e.g. here's a PR that is just several hours old, builds on latest master and is green #557). So, once you rebase this branch on latest master, the linting issues should just magically vaporize (hint: because latest master is on a newer mypy version etc).

Hm, but every new test run is supposed to merge with master before running tests, so it should have all the latest changes on master.

It's not so much that I want to fix the problem of this PR having a ❌ -- it's that this ^ mechanism I thought should prevent the problem of testing on old PRs. If it's not solving the problem, I want to understand why and maybe try to fix it.

[pipermerriam]

I pushed my changes from the last few weeks.

[veox]

For PR #608 (not yet merged):

- `#608 <https://github.com/ethereum/trinity/pull/608>`_: Tests: Run tests for Constantinople and Petersburg

[veox]

For PR #623 (not yet merged):

- `#623 <https://github.com/ethereum/trinity/pull/623>`_: Tests: Optimise for faster run times

[carver]

I'm starting to clean and finish up the release notes for today's trinity release. If you have any more additions, please make a comment instead of editing the PR.

[carver]

Wow, we clearly waited too long between releases. (I mean we already knew that, but this changelog is enormous.)