Create versioned releases

[fulldecent]

Please uses GitHub releases or an RSS feed to announce draft resolutions here.

I would like a chance to review proposed changes and participate in discussion BEFORE decisions are made.

[timbeiko]

Sure, we can use releases. What do you think a release should "be"? Should we have a new RC each time an EIP is added to a network upgrade and then the release when the upgrade is finalized?

[fulldecent]

Thank you. At a minimum, this represents a consensus change and each version should be a major version.

So London would be 7.0.0 or something.

If there is a change that is not breaking, possibly a a new optional way to compress data between peers, that would be a 7.1.0 release on top of that.

I'm not exactly sure how the decisions are made for choosing the next hardfork. But if EIPs are added one at a time and the trigger can be pulled any time, then yes I agree a new 7.0.0rc1 is appropriate each time.

But if inclusions EIPs are just discussions and there is actually only one decision to launch to testnet, then maybe only need to release an RC every time there is a deployment on testnet.

[timbeiko]

I kind of disagree with major versions here, given the already prevailing use of "Ethereum 2.0". IMO it would be a bit more appropriate for spec versions to be, say, 1.x.y, pre-merge and then after the merge start using 2.x.y. This seems to be what eth2.0-specs is using.

As for choosing the next hard fork, the process is listed here. If you assume a certain upgrade is represented by the middle digit (e.g. 1.1.y), then perhaps we can increment y each time a change is made to either include EIPs in a devnet, or to move them to the network upgrade spec, with at most one release every 2 weeks aside from emergencies.

[SamWilsn]

Maybe we could use expected date based versions (like Ubuntu)? 1.21.08 for London, for example.

I think we can expect to have a major version bump at least once a century ;)

[timbeiko]

That works for me too!

[fulldecent]

That's okay, but we should be clear about specifying (i.e. documenting) the versioning strategy.

If we were using SemVer, this would be about the 10th major release of Ethereum and "Ethereum 2" would be a separate project entirely or it would just be the 11th major version.