Skip to content

Conversation

@lightclient
Copy link
Member

When I implemented in #31340 I didn't expect multiple forks to be configured at once, but this is exactly how BPOs are defined. This updates the method to determine the next scheduled fork rather than the last fork.

Additionally I missed the fork<>string map when adding the BPOs, so adding those here too.

Copy link
Member

@MariusVanDerWijden MariusVanDerWijden left a comment

Choose a reason for hiding this comment

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

LGTM

@lightclient lightclient merged commit 339cae8 into ethereum:master Sep 18, 2025
5 of 6 checks passed
@lightclient lightclient added this to the 1.16.4 milestone Sep 18, 2025
Sahil-4555 pushed a commit to Sahil-4555/go-ethereum that referenced this pull request Oct 12, 2025
When I implemented in ethereum#31340 I didn't expect multiple forks to be
configured at once, but this is exactly how BPOs are defined. This
updates the method to determine the next scheduled fork rather than the
last fork.
atkinsonholly pushed a commit to atkinsonholly/ephemery-geth that referenced this pull request Nov 24, 2025
When I implemented in ethereum#31340 I didn't expect multiple forks to be
configured at once, but this is exactly how BPOs are defined. This
updates the method to determine the next scheduled fork rather than the
last fork.
prestoalvarez pushed a commit to prestoalvarez/go-ethereum that referenced this pull request Nov 27, 2025
When I implemented in ethereum#31340 I didn't expect multiple forks to be
configured at once, but this is exactly how BPOs are defined. This
updates the method to determine the next scheduled fork rather than the
last fork.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants