substrate-api-client icon indicating copy to clipboard operation
substrate-api-client copied to clipboard

Published 20 hours ago • verified publisher icon scs

New release names in polkadot-sdk

Open Niederb opened this issue 1 year ago • 6 comments

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?

Niederb avatar Sep 02 '24 09:09 Niederb

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?

haerdib avatar Sep 03 '24 08:09 haerdib

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/

Niederb avatar Sep 03 '24 13:09 Niederb

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.3.0. Does this sound correct @Niederb ?

haerdib avatar Sep 19 '24 06:09 haerdib

Yes, that's the general idea

Niederb avatar Sep 19 '24 12:09 Niederb

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.x.0
  • [ ] create a new branch pointing to the respective release branch (is this still needed?)

Or should we wait with the version 1.x.0 for something specific?

haerdib avatar Sep 19 '24 13:09 haerdib

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

Niederb avatar Sep 24 '24 06:09 Niederb

See #809

Niederb avatar Nov 04 '24 12:11 Niederb