cerc-io/go-ethereum
13
0
Fork 0
Code Issues 9 Pull Requests Packages Projects Releases 66 Wiki Activity

[v5] Rebase to 1.11.5 #340

New Issue
Closed
opened 2023-03-16 19:26:50 +00:00 by i-norden · 9 comments
i-norden commented 2023-03-16 19:26:50 +00:00
Member
Copy Link

1.11.5 was released last week, we need to update our custom geth client to work on top of this release.

This rebase is required before April 12th

Note: there are consensus breaking changes and numerous EIPs in this upgrade, so it will likely be a relatively heavy rebase.

  • v5 geth

After cutting a release, we will need to update the following v5 versions of the repos to use this release:

  • eth-statediff-service
  • ipld-eth-server
  • ipld-eth-db-validator
  • ipld-eth-state-snapshot
  • eth-statediff-fill-service
  • ipld-eth-statedb

We will also need to update and release v5 versions of the following repos that use the root v1.11.5 release:

  • ipfs-ethdb
  • leveldb-ethdb-rpc
  • eth-ipfs-state-validator

Might need to update

  • tx_spammer
[1.11.5](https://github.com/ethereum/go-ethereum/releases/tag/v1.11.5) was released last week, we need to update our custom geth client to work on top of this release. **This rebase is required before April 12th** Note: there are consensus breaking changes and numerous EIPs in this upgrade, so it will likely be a relatively heavy rebase. - [x] v5 geth After cutting a release, we will need to update the following v5 versions of the repos to use this release: - [ ] eth-statediff-service - [ ] ipld-eth-server - [ ] ipld-eth-db-validator - [ ] ipld-eth-state-snapshot - [ ] eth-statediff-fill-service - [ ] ipld-eth-statedb We will also need to update and release v5 versions of the following repos that use the root v1.11.5 release: - [x] ipfs-ethdb - [x] leveldb-ethdb-rpc - [ ] eth-ipfs-state-validator Might need to update - [x] tx_spammer
i-norden commented 2023-03-29 21:02:54 +00:00
Author
Member
Copy Link

During the rebase upgrade from v1.10.25 to v1.10.26, our commits were not squashed (see our intervening commits between fda1723 and 69568c5 in https://github.com/cerc-io/go-ethereum/commits/v1.11.5-statediff-5.0.0-alpha?after=e577ea3f56e59854f4c98c7262894e8cddb6b33c+104&branch=v1.11.5-statediff-5.0.0-alpha&qualified_name=refs%2Fheads%2Fv1.11.5-statediff-5.0.0-alpha.

During the [rebase upgrade](https://github.com/cerc-io/go-ethereum/releases/tag/v1.10.26-statediff-4.2.2-alpha) from v1.10.25 to v1.10.26, our commits were not squashed (see our intervening commits between fda1723 and 69568c5 in https://github.com/cerc-io/go-ethereum/commits/v1.11.5-statediff-5.0.0-alpha?after=e577ea3f56e59854f4c98c7262894e8cddb6b33c+104&branch=v1.11.5-statediff-5.0.0-alpha&qualified_name=refs%2Fheads%2Fv1.11.5-statediff-5.0.0-alpha.
i-norden commented 2023-03-29 22:32:46 +00:00
Author
Member
Copy Link

And all the upstream changes in v1.10.26 we squashed into fda1723, so we lost that incremental history and retaining that was the main point of our rebase scheme 👍

And all the upstream changes in v1.10.26 we squashed into fda1723, so we lost that incremental history and retaining that was the main point of our rebase scheme 👍
i-norden commented 2023-03-29 22:35:48 +00:00
Author
Member
Copy Link

It also means we have to decide whether to now squash back to fda1723 or 69568c5 for the next rebase, squashing to the former preserves the upstream v1.10.26 history (but not really, it just preserves it within that single squashed commit aka useless) but means we have to resolve conflicts for all the commits from 69568c5 to fda1723. Squashing down to 69568c5 blows away the v1.10.26 upstream history entirely, but goes back to our regular workflow that only requires resolving conflicts for a single commit.

It also means we have to decide whether to now squash back to fda1723 or 69568c5 for the next rebase, squashing to the former preserves the upstream v1.10.26 history (but not really, it just preserves it within that single squashed commit aka useless) but means we have to resolve conflicts for all the commits from 69568c5 to fda1723. Squashing down to 69568c5 blows away the v1.10.26 upstream history entirely, but goes back to our regular workflow that only requires resolving conflicts for a single commit.
i-norden commented 2023-03-29 22:44:47 +00:00
Author
Member
Copy Link

Of those two I'm inclined to do the latter, since the v1.10.26 history is pretty much useless in the squashed form. And otherwise we will have to continue resolving conflicts for this set of intervening commits in every future rebase.

Of those two I'm inclined to do the latter, since the v1.10.26 history is pretty much useless in the squashed form. And otherwise we will have to continue resolving conflicts for this set of intervening commits in every future rebase.
i-norden commented 2023-03-29 22:47:01 +00:00
Author
Member
Copy Link

A third option is to roll back to https://github.com/cerc-io/go-ethereum/releases/tag/v1.10.25-statediff-4.2.1-alpha and then correctly re-apply all changes and rebases since then. This is the correct way to do it but will take a relatively long time.

A third option is to roll back to https://github.com/cerc-io/go-ethereum/releases/tag/v1.10.25-statediff-4.2.1-alpha and then correctly re-apply all changes and rebases since then. This is the correct way to do it but will take a relatively long time.
i-norden commented 2023-03-29 22:57:05 +00:00
Author
Member
Copy Link

The cost of the third option is amplified by the need to do it for both v4 and v5

The cost of the third option is amplified by the need to do it for both v4 and v5
i-norden commented 2023-03-30 13:50:07 +00:00
Author
Member
Copy Link

A fourth option that I should have recognized earlier: checkout fresh upstream v1.11.5 and simply merge our latest working branch in. First need to collect and cache our work somewhere, so it can be applied ontop as a single commit instead of interweaving with the upstream history.

A fourth option that I should have recognized earlier: checkout fresh upstream v1.11.5 and simply merge our latest working branch in. First need to collect and cache our work somewhere, so it can be applied ontop as a single commit instead of interweaving with the upstream history.
i-norden commented 2023-03-30 22:45:01 +00:00
Author
Member
Copy Link

The v4 rebase is easy because Mike had already gone back and fixed this in the latest v4 release

The v4 rebase is easy because Mike had already gone back and fixed this in the latest v4 release
i-norden commented 2023-03-31 14:58:46 +00:00
Author
Member
Copy Link

Closing this, the remaining repos need to be refactored to work with v5 which is substantially more than a simple rebase. Each repo has an issue to track this, and this top-level issue: https://github.com/cerc-io/issue_tracking/issues/38

Closing this, the remaining repos need to be refactored to work with v5 which is substantially more than a simple rebase. Each repo has an issue to track this, and this top-level issue: https://github.com/cerc-io/issue_tracking/issues/38
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
bug

   
critical

   
duplicate

   
enhancement

   
epic

   
help wanted

   
in progress

   
invalid

   
low priority

   
question

   
rebase

   
v1

   
v5

   
wontfix
  
Copied from Github

An issue or PR manually copied from GitHub.

  
Kind/Breaking

Breaking change that won't be backward compatible

  
Kind/Bug

Something is not working

  
Kind/Documentation

Documentation changes

  
Kind/Enhancement

Improve existing functionality

  
Kind/Feature

New functionality

  
Kind/Security

This is security issue

  
Kind/Testing

Issue or pull request related to testing

  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

No Label
bug
critical
duplicate
enhancement
epic
help wanted
in progress
invalid
low priority
question
rebase
v1
v5
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/go-ethereum#340
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?