On Naming Upgrades
On ACD118, the topic of the next upgrades came up, along with their naming. There are a few different things to decide on this front:
City Name vs. Two-Words for Ice Age
The first point was whether we should stick to our city name terminology or use a two-word name for the December upgrade, which will have to update the Ice Age (assuming The Merge is not ready), and may contain additional EIPs. @axic shared some thoughts on Github about this:
On the topic of naming: there was a time we used two-word names, and then somehow we ended up on the city-name track (starting with Byzantium). In this city-name era, the only two-word update is Muir Glacier, which is both a non-feature update and somewhat a “unplanned update”.
I am slightly leaning towards keeping the city names for every feature update (including the merge), as long as there is a single feature apart from the difficulty bomb. And keeping everything else with a different name.
In case there will be only a difficulty bomb change, I suggest we look for another retreating glacier perhaps in so far unrepresented regions, such as Africa or Oceania: Arrow Glacier or Tasman Glacier sounds like an interesting one.
The counter argument is that following the devcon names provides more predictability for people looking at the “Ethereum roadmap” (e.g. we know Shanghai is in December, and it is followed by Cancun, etc.).
If you have a preference, please share it here.
- City names (Shanghai = December, Cancun = X, etc.)
- Two word name for Ice Age ( Arrow Glacier = Difficulty Bomb, Shanghai = EIP X, Y, Z)
“The Merge” as a special name
Should we use a city name for “The Merge”, or should we use a city name (e.g. Cancun)?
- The Merge
- City Name (Cancun, Prague, etc.)
Time-based vs. Content-based Updates
Another question that was discussed on the call is whether we should try and adhere to strict schedules in our network upgrades (as argued by @MicahZoltu here), or whether we should aim to define what the “big initiative” in a upgrade is, roughly schedule it, but be flexible to ensure that this large feature is delivered (as argued by me here).
- Strict Time-Based Upgrades
- “Large Initiative”-Based Upgrades