New release names in polkadot-sdk

scs / substrate-api-client

Library for connecting to substrate API over WebSockets

Apache License 2.0

260 stars 124 forks source link

New release names in polkadot-sdk #800

Closed Niederb closed 3 weeks ago

Niederb commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

Yes, that's the general idea

haerdib commented 2 months ago

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 commented 2 months ago

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

Niederb commented 3 weeks ago

See #809