Add releasing guidelines

[SamWilsn]

What was wrong?

Related to Issue #290

How was it fixed?

Added a document describing the release process.

Cute Animal Picture

[danceratopz]

This is excellent, thanks Sam! Looks good to me.

I caught myself mentally mapping dev to "devnet", but my brain's getting used to it (it's a shame .pre doesn't exist).

The "preview" -> "finalize" -> "bugfix" devnet flow maps well to the new devnet launch process: Launch now requires all hive tests to pass.

I wrote a script to ensure the versions are valid and tried to generate a human readable version of all the releases included in this doc, here's the output:

1.15.0rc1.dev1         EELS (v1) release of Cancun for devnet-1, pre-release-v1
1.15.0rc1.dev2         EELS (v1) release of Cancun for devnet-1, pre-release-v2
1.15.0rc1.dev3         EELS (v1) release of Cancun for devnet-1, pre-release-v3
1.15.0rc1              EELS (v1) release of Cancun for devnet-1 (version at devnet launch)
1.15.0rc1.post1        EELS (v1) release of Cancun for devnet-1, bug-fix-release-1
1.15.0rc1.post2        EELS (v1) release of Cancun for devnet-1, bug-fix-release-2
1.15.0rc1.post3        EELS (v1) release of Cancun for devnet-1, bug-fix-release-3
1.15.0rc2              EELS (v1) release of Cancun for devnet-2 (version at devnet launch)
1.15.0                 EELS (v1) release of Cancun for mainnet (version at hardfork)
1.15.1                 EELS (v1) release of Cancun for mainnet, bug-fix-release1 (post hardfork)
2.15.0                 EELS (v2) release of Cancun for mainnet (version at hardfork)
2.16.0rc1.dev1         EELS (v2) release of Prague for devnet-1, pre-release-v1
2.16.0rc1              EELS (v2) release of Prague for devnet-1 (version at devnet launch)
2.16.0                 EELS (v2) release of Prague for mainnet (version at hardfork)
1.3.5                  EELS (v1) release of Tangerine Whistle for mainnet, bug-fix-release5 (post hardfork)
1.4.0                  EELS (v1) release of Spurious Dragon for mainnet (version at hardfork)
1.4.0rc1               EELS (v1) release of Spurious Dragon for devnet-1 (version at devnet launch)
1.3.6                  EELS (v1) release of Tangerine Whistle for mainnet, bug-fix-release6 (post hardfork)
2.3.0                  EELS (v2) release of Tangerine Whistle for mainnet (version at hardfork)
1.3.0rc5               EELS (v1) release of Tangerine Whistle for devnet-5 (version at devnet launch)
1.3.0rc6               EELS (v1) release of Tangerine Whistle for devnet-6 (version at devnet launch)
1.3.0rc5.post1         EELS (v1) release of Tangerine Whistle for devnet-5, bug-fix-release-1
2.3.0rc5               EELS (v2) release of Tangerine Whistle for devnet-5 (version at devnet launch)
1.3.0rc5.post7         EELS (v1) release of Tangerine Whistle for devnet-5, bug-fix-release-7
1.3.0rc5.post8         EELS (v1) release of Tangerine Whistle for devnet-5, bug-fix-release-8
1.3.5.dev7             EELS (v1) release of Tangerine Whistle for mainnet, bug-fix-release5 (post hardfork), pre-release-v7
1.3.5.dev8             EELS (v1) release of Tangerine Whistle for mainnet, bug-fix-release5 (post hardfork), pre-release-v8
1.3.0rc5.dev7          EELS (v1) release of Tangerine Whistle for devnet-5, pre-release-v7
1.3.0rc5.dev8          EELS (v1) release of Tangerine Whistle for devnet-5, pre-release-v8
1.3.0rc5.post7.dev9    EELS (v1) release of Tangerine Whistle for devnet-5, bug-fix-release7, pre-release-v9
1.3.0rc5.post7.dev10   EELS (v1) release of Tangerine Whistle for devnet-5, bug-fix-release7, pre-release-v10

[SamWilsn]

I wrote a script to ensure the versions are valid and tried to generate a human readable version of all the releases included in this doc

That's super cool! Would you be willing to make it into a lint (similar to import_hygiene.py)?

[raxhvl]

Are we aiming for compatibility with semver?

[SamWilsn]

Are we aiming for compatibility with semver?

Added a bit of text explaining it, but in short, no.

[raxhvl]

The two information: EELS API for downstream apps + network dependency (upstream for EELS) is fighting for real estate in the version string. Each require their own "dev" namespace.

This causes jumping of minor versions when there is a breaking change in EELS. Say 1.16.0 to 2.17.0 (where >=2.0.0, <2.16.0 releases may not exist!); this is because we use minor to represent fork.

We could separate this out using a local identifier for forks:

This can be extended to include release (or dev) candidates for EELS.

[SamWilsn]

Each require their own "dev" namespace.

The benefit of having two namespaces would be to express "a preview of code for the final specification" and "final code for a preview of the specification" separately?

releases may not exist!

Are missing releases a problem? If so, why?

We could separate this out using a local identifier for forks

Unfortunately you cannot publish packages with local identifiers to PyPI:

As the Python Package Index is intended solely for indexing and hosting upstream projects, it MUST NOT allow the use of local version identifiers.