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

Change "Hard Fork" for "Network Upgrade" #2516

Closed
wants to merge 2 commits into from
Closed

Change "Hard Fork" for "Network Upgrade" #2516

wants to merge 2 commits into from

Conversation

timbeiko
Copy link
Contributor

It seems the consensus within the Ethereum community is now to use "network upgrade" over "hard fork". This change updates EIP-1 to reflect this.

There was a conversation about this in a different PR (see #2508 (comment)), but for visibility I wanted to separate this into a distinct PR.

From the PR linked above:

FWIW, "network upgrade" is what is currently used in communications from the EF, see Muir Glacier, Istanbul, Constantinople. Last use of "hard fork" was for Byzantium.

@edsonayllon
Copy link
Contributor

edsonayllon commented Mar 1, 2020

I do agree on changing the term "hard-fork." As, hard-fork has associations with Bitcoin Cash/Bitcoin, and Ethereum Classic/Ethereum, where hard-fork can be interpreted as splitting, instead of pivoting towards an improvement. The term "hard-fork" may invoke some degree of unnecessary resistance, however small that may be.

But, I'm also at the perspective of preferring the term "update" over "upgrade." "Upgrade" for every hard-fork may not be completely correct, as something like delaying the difficulty bomb may need a hard-fork, but isn't necessarily an upgrade, more-so keeping things operational as they have been. Using the term "upgrade" for a fork that doesn't really provide much upgrading may be bad for PR.

I think Microsoft and Apple use the term "update" to label changes to their operating systems, and then specify what kind of update, either a feature update (an upgrade), or a maintenance update, and then there are performance updates. Using "update" looks like a good idea.

@Souptacular
Copy link
Contributor

I have come around to accepting that network upgrade is a better term than hard fork because of the connotations around hard fork described by Edson and Tim. I do want to advocate for "network upgrade" vs "network update".

An Ethereum update to me implies a client update that updates your node to perform enhancements or optimizations at the client level. Upgrade is a term with more weight that to me indicates that major changes have occurred requiring all to upgrade. Additionally, ZCash uses network upgrades and I think we shouldn't make a third term within major cryptocurrency networks. I support using "network upgrade".

Example of ZCash using network upgrade terminology: https://z.cash/upgrade/blossom/

@timbeiko
Copy link
Contributor Author

+1 on "upgrade" vs. "update".

@edsonayllon
Copy link
Contributor

I see. Network upgrade is fine with me.

@Souptacular
Copy link
Contributor

LGTM. We should merge now that we have decided that network upgrade is the right vernacular.

@timbeiko the last thing you need to do is add a line to the History section at the bottom of EIP-1 to indicate the change.

@axic
Copy link
Member

axic commented Apr 22, 2020

Does changing that single instance in EIP-1 have any measurable effect? The "hard fork metas" are still called like that.

If terminology change is wished, probably a good step would be getting an agreement from ACD for the new terminology and applying that cross the EIP repo.

@Souptacular
Copy link
Contributor

@axic good point. @timbeiko what do you think?

@timbeiko
Copy link
Contributor Author

@axic good point. Do you think the ACD gitter is the best place to bring this up? The calls seem not ideal.

@axic
Copy link
Member

axic commented Apr 22, 2020

Probably getting buy-in from clients would be a good way, so that their messaging also uses the new terminology.

@timbeiko
Copy link
Contributor Author

timbeiko commented May 4, 2020

Closed in favor of #2624

@timbeiko timbeiko closed this May 4, 2020
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.

4 participants