reset a couple of versions down from v2.0

[rphmeier]

For things that we don't yet want to stabilize, but may want to later!

[tomaka]

If we're doing that, I'd put network in there as well.

EDIT: nevermind, it's still at 0.8.0

[rphmeier]

@tomaka network was already at 0.8, but network-gossip wasn't. network-test isn't either. I'm done pushing for now so just go for it on this branch :P

[bkchr]

@pepyakin you maybe want to downgrade something as well?

[gui1117]

staking has been downgraded, 2.0 should include #4407

[gui1117]

It would be great not to make session module 2.0 if we want to change the interaction between staking and session 🤔

[gui1117]

the branch gui-rh-shaky-decrease-pallet-session decrease session to 0.8, I actually wonder about how much we want to stabilize for pallets. Stabilizing primitives and frame-* is important but maybe pallets themselves should be able to break change more quickly.

[bkchr]

@thiolliere if you a certain that we will need to break something for the session module, than please push the downgrade to this branch.

[gavofyork]

for (non-consensus) pallets i'm happy to stabilise and bump the major version as needed. they're very much downstream on the dependency tree and i see little problem with keeping multiple major versions of them i crates.io.

primitives-* and frame-* are the important ones to not change following stability.

[gui1117]

if I decrease pallet-session to 0.8 I also need to decrease pallet using it to 0.8 as when I will upgrade session I will need to upgrade those pallets as well. and pallet using session are: grandpa, babe, im-online, authority-discovery, aura.

I'll do my best to commit the API of session as soon as possible

[rphmeier]

I agree with Gav - The 2.0 release should be stabilizing everything non-consensus in frame, especially since that's the part of the code that users will reference the most. This PR should only be destabilizing core crates whose API we shouldn't worry about breaking for some time to come.

@thiolliere

It would be great not to make session module 2.0 if we want to change the interaction between staking and session 🤔

Do you have a link to a writeup of what this would entail? First I've heard of it (this issue isn't the place to discuss further, though)

if I decrease pallet-session to 0.8 I also need to decrease pallet using it to 0.8 as when I will upgrade session I will need to upgrade those pallets as well

I don't believe this is true as long as the API of the pallets using it is stable.

[gui1117]

It would be great not to make session module 2.0 if we want to change the interaction between staking and session thinking

Do you have a link to a writeup of what this would entail? First I've heard of it (this issue isn't the place to discuss further, though)

This comes from #4407 especially this paragraph:

The Session module should, at the end of a session, report the accrued points of each validator together with the era number that the validator set is from back up to the Staking module, giving it full information about which validators should be rewarded. (It should explicitly report so that the number of sessions that the validator set lags behind continues to be immaterial for the Staking module.)

But after some talks it seems this information can be carried by the current pallet-session API, but better to be made explicit in API as written in #4609

[gavofyork]

---- service::tests::test_sync stdout ----
70 thread 'service::tests::test_sync' panicked at 'Waited for too long', client/service/test/src/lib.rs:124:14

[gavofyork]

?!

[bkchr]

I think it would be nice to let the crate version follow the actual metadata version. We will have new metadata versions and each will require a major bump anyway.

[gavofyork]

sp-state-machine and sp-externalities are both downgraded to pre 1.0, yet they're primitives and i would really hope we can stabilise primitives for a while. what's the deal here?

[rphmeier]

cc @bkchr @pepyakin - those changes appear to be yours.

[pepyakin]

@gavofyork My motiviation w.r.t sp-state-machine is that I was thinking about shuffling some stuff between sc-executor and sp-state-machine. I am not strong on this. Although I am a little bit worried that it might hinder @cheme 's efforts w.r.t to #3263.

[bkchr]

sp-state-machine and sp-externalities are both downgraded to pre 1.0, yet they're primitives and i would really hope we can stabilise primitives for a while. what's the deal here?

sp-externalities will require some more love. We can just remove the Externalities trait from sp-core and than we can have a stable release.

[gavofyork]

need resolving

[rphmeier]

Will merge as-is and we can revisit stabilizing primitives.