Conversation
This EIP provides a canonical reference for Ethereum network upgrade naming conventions, documenting the evolution and rationale behind naming practices across various upgrade types.
github-actions
bot
added
c-new
File
|
Updated Upgrade Nomenclature document with links to EIPs for various Ethereum upgrades and added references for historical context.
joshdavislight
left a comment
joshdavislight
left a comment
There was a problem hiding this comment.
Interestingly, the I* fork is slated to be Istanbul, which starts with an I and is the name of a previous fork.
Replace `SHUOLD` with `MAY` & add another Devconnect city name.
- Update host city references and format for upgrade names. - Intentionally removed link to WIP upgrade Meta.
poojaranjan
changed the title
eth-bot
changed the title
|
don't we have EIP to keep track of hardfork meta EIPs? |
As per my understanding, each hard fork originally had an independent Meta EIP. That practice was later discontinued, and instead, a single .md file per upgrade was introduced as part of a process change. Since the upgrade.md files had already been created, the EIP-7568:Hardfork Meta Backfill – Berlin to Shapella was added as a one-time exception to list the missing upgrades. Are you referring to any other EIP by any chance, or is there a specific case you had in mind? |
SamWilsn
left a comment
SamWilsn
left a comment
There was a problem hiding this comment.
This has the correct EIP shape, but I don't want to approve immediately, since it is an Informational proposal (and I'm sure other Editors have opinions on it). Consider this my approval, but I'll wait for more comments before merging.
The renderer can do this, if we want to write some ruby. |
Update "require" EIPs
Arrange "requires" in ascending order to fix bot's error
|
The commit 2ecce3a (as a parent of c2316ae) contains errors. |
|
i would prefer rendering solutions than book keeping manual solutions - or to even go a step further AI powered summaries |
|
what could be useful for this EIP which it does as well is to record the nomenclature process, but then this EIP needs to be a living EIP so that it can be modified if the nomenclature changes as this anyway documents all the changes in past/present/future. also would like to avoid the bloat of "process documentation" EIPs which are essentially good, but good to just have limited EIPs which describe the processes |
As per EIP-1, an Informational EIP can provide general guidelines or document information for the Ethereum community. This EIP simply records the naming process that has already been followed in the past. It does not introduce a new rule or change the protocol. It is fine to move it through the normal EIP status flow and eventually mark it as Final, similar to EIP-6953: Network Upgrade Activation Triggers and perhaps a future candidate will be EIP-8066: Upgrade Mascots. It does not need to be "Living". Future upgrade names can continue to come from the Hardfork Meta EIP. If the naming process changes in the future, a new Informational EIP can be written. Merging this will help document history and provide clarity without adding complexity. |
|
As an action item from the EIP Editing Office Hour 89, a |
7 participants
This EIP provides a canonical reference for Ethereum network upgrade naming conventions, documenting the evolution and rationale behind naming practices across various upgrade types.