New release names in polkadot-sdk

[Niederb]

polkadot-sdk change to a different naming schema for their releases:
https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-stable2407

We should look into what this means for us. Should we also change the naming of our releases and branches?

[haerdib]

Yes, we should definitely change our release name as well.
Suggested branch name: polkadot-stableXXXX or polkadot-stableXXXX-X (exactly the same as the one Parity uses). What do you think?

As crates.io is now used by Parity and our users as well, we should probably add a crates.io release cycle as well. Are we doing something like that already?

[Niederb]

I have to say I'm not a big fan of the naming approach of parity. I find it very unclear how stable2407, stable2407-1 and stable2407-02 are related (for example stable2407-2 was released in September). Still I think for the branches it makes sense to use the same as parity.
I wonder if for crates.io a release is always tied to a polkadot release? And how does a user know which polkadot version is supported?
Parity seems to write a version in the tagline of the crate which again does not make sense to me as this is not tied to a version: https://crates.io/crates/pallet-timestamp/

[haerdib]

Idea from encointer: Use major version to indicate a new api-client release and minor for polkadot updates.

E.g. 1.2.0 -> version 1 from api-client and version 2 of polkdaot. If polkadot updates and we follow, it will be released as 1.3.0.
If the api-client creates a new release it will be 2.0.0. Does this sound correct @Niederb ?

[Niederb]

Yes, that's the general idea

[haerdib]

Then a concrete TODO to solve this issue would be:

• update to newest parity release (on github master, whichever commits fits the newest release)
• publish a new crates.io release with the version 1.0.0
• create a new branch pointing to the respective release branch (is this still needed?)

Or should we wait with the version 1.0.0 for something specific?

[Niederb]

If we adapt the versioning approach I would increase the major version to prevent/reduce confusion when someone is updating

[Niederb]

See #809