Vlad Frolov
Vlad Frolov
@ori-near May I ask you to review this proposal?
@joshuajbouw The most recent update I am aware of is here: https://github.com/near/NEPs/issues/246#issuecomment-1295118218
cc @bowenwang1996
> The problem here is that reverting a version after it has been instantiated (no matter how we instantiate it, through flags or protocol upgrades) is difficult. This seems to...
Just to sum up the solution we seem to arrive from the implementation point of view: Use compile-time Rust features to guard nightly implementations defined in Cargo.toml and use `stable-protocol`...
I vote for that we only deploy nightly over stable, and don't bother with nightly to nightly migrations (dump some stable state, and recover from it [hard fork] -- do...
That makes sense. Let's stick to independent FEATURES_MAPPING then (though, I would add some [compile-time sanity checks preventing stable having some features enabled without being enabled in nightly](https://github.com/near/nearcore/pull/3503#discussion_r509075990)).
Sounds good to me. My only ask is to have a good infrastructure for testing feature stabilization PRs making sure the migrations are fine on real data and older nodes...
@Canvinus Thanks for the details about SourceScan. I hope we can adjust SourceScan to use contract metadata, so it can handle contracts verification passively. It is not unique setup, so...
@Eren-Yeaager thanks for reporting it. We don’t have Windows boxes to debug it and our CI for Windows works just fine, so I don’t know how to help you here....