Comments (18)
So, I would like to merge the following pr first: #63
After this pr is merged, we can update this pr #26 and then finally do the release.
from runtimes.
No action item needed for paritytech/polkadot-sdk#125 in this release.
Context: VoteLockingPeriod
was mistakenly set to 7 days, and in this release it is going back to 28, the value that it should be. This will not impact the user's voting power. At the moment, the lock can be removed sooner than expected in Polkadot. Once we fix this, the locks will be according to the spec. Implementing polkadot-fellows/RFCs#20 (comment) is a different concern and probably will need consideration, but is outside the scope of this release.
from runtimes.
o just copying the changes instead of the full history?
Yes
Replacing the dependencies to use crates-io instead of git? okay.
I mean I hope we get the latest release this week on crates.io, otherwise we need to use git dependencies.
from runtimes.
#28 it is being worked on here.
And yes it will be passed on 1.1.0.
from runtimes.
We need to wait for the staking changes runtime upgrade to be approved. After that is approved, we need to merge this fix here to make the repo canonical again. Then we can bring the release over the finish line. I think we can actually do that before the fix is enacted on chain, but we should be certain that it gets enacted on chain.
Maybe we can then do the next release faster...
from runtimes.
No this will not be included anymore. This can go into the next release. We want to start with the next release shortly after this was has finally be dine (which is hopefully today).
from runtimes.
BTW, this time we don't want to copy the commits as before. From this point on this repo will work independently from the Parity repos when it comes to updating the runtimes. The runtimes in this repo are also the canonical ones.
from runtimes.
So, we first need to wait for this next node release to happen. After the release happened, someone can propose a pull request that updates to these crates on crates.io.
Replacing the dependencies to use crates-io instead of git? okay.
BTW, this time we don't want to copy the commits as before. From this point on this repo will work independently from the Parity repos when it comes to updating the runtimes. The runtimes in this repo are also the canonical ones.
π so just copying the changes instead of the full history?
from runtimes.
Whatβs the timeline here? When can we expect a new runtime release?
Seeing how node v1.1.0 is out should we not release runtimes 1.1.0 directly (instead of v1.0)?
from runtimes.
#28 was merged. Can we do a release now? We need a runtime release for BEEFY on Kusama.
Anything I can help with getting this over the finish line?
from runtimes.
Ok, thanks for the context! π
from runtimes.
Also required:
- #46
- paritytech/polkadot-sdk#1733 (IMO this is a short term solution but will allow backwards compatibility for some XCM programs already being sent)
- Fix failing integration tests that causes parachains to stall: Needs paritytech/polkadot-sdk#1920 backported to node release(s).
from runtimes.
from runtimes.
Reason why Parachains stall after relay chain runtime upgrade: paritytech/polkadot-sdk#1923 (comment)
from runtimes.
We should not forget to bump the spec_version
s.
from runtimes.
Let's also get
released.
We want to go live with the Polkadot<>Ethereum bridge by end of year, meaning BEEFY should be active on Polkadot before December.
And activating it has a long tail of actions:
- release runtime
- upgrade runtime
- coordinate validators to rotate keys (register BEEFY keys)
- governance to enable BEEFY
If we include it in this release we can do 1-3 in parallel for Kusama and Polkadot. Then do 4 on Polkadot once we're happy with stability on Kusama.
Waiting for next release means doing 1->4 between next release and end of December which won't be possible unless fellowship does another release 2, max 3 weeks from now...
from runtimes.
To not break every downstream user as we have renamed the xcm
crate to staging-xcm
to have it released on crates.io, I have created the following two prs:
With these two prs we will have TypeInfo::path
not return staging-xcm
as one segment and instead xcm
. So, the metadata type name shouldn't change and downstream users should not need to change anything. A proper solution is being discussed here: polkadot-js/api#5741 TLDR: Do not reference the type by name as there might be dragons ;)
We will require that both prs are merged and the appropriate crates being relased. For the staging-xcm
crate we will need to backport the changes to 1.1.0
and 1.2.0
and release a patch release of the staging-xcm
crate.
from runtimes.
Done
from runtimes.
Related Issues (20)
- [Ambassadors] Reduce `MaxRank` to 3 HOT 1
- `Fail when author pushes new code` should check if the user is not a fellow HOT 1
- Optimistic Project Funding HOT 22
- Implement Unbrick Collective HOT 3
- [CI] Publish unoptimized runtime blobs for debugging HOT 2
- [People] Add new registrar HOT 11
- PeopleKusama, PeoplePolkadot and Encointer don't have price for parent delivery set up HOT 2
- Add fee estimation support for XCMs over P<>K and P<>E bridges
- Treasury Configuration(s) for Multi-Chain Spends HOT 1
- [bridges][AHs] Include ExportMessage fees in XCM message from AH to BH HOT 2
- Update CI for Polkadot People Chain HOT 2
- Remove `chain-spec-generator`
- Check `merge bot` and required pipelines HOT 8
- Add test for coretime Runtime API HOT 1
- Coretime Runtime API: Refactor `burn_at_relay`
- Review bot error: Reviews may only be requested from collaborators HOT 6
- Field `image` on people chain is unusable HOT 5
- Enable StorageWeightReclaim for all the runtime HOT 2
- Consider using `RuntimeGenesisConfig` instead of directly constructing json for the preset genesis patch
- Actually benchmark `pallet_xcm::execute` for all runtimes HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from runtimes.