Create parachain runtime excluding Zero/GameDAO pallets

[vayesy]

No description provided.

[2075]

did you decide it is faster to build a lean one and then new features are added step by step and added via feature flags? @vasylenko-yevhen

[vovacha]

Suggested change

	version = "0.1.0"
	version = "3.1.60"

[vovacha]

Or should it start from 0? We have release-3.1.60 and parachain's runtime version is 0.1.0. A bit confusing.

[vayesy]

Versioning approach is not clear to me for this runtime. Since it does not contain any Zero/GameDao features/pallets, is there any sense following same versioning now?
I was thinking of setting up correct version number at the moment, when we would enable these pallets in the runtime and leave it 0.1.0 for now, like a pre-release.
What's your opinion on that?

[2075]

• the versioning for runtime / node can be separate from zero pallets and gamedao pallets.

• also we need to come up with a release plan where we show node / runtime version x has zero / gamedao pallets y,z,a,b,...

• the version 1 as discussed for the stable env, how would that relate to the parachain versioning now? we should discuss maybe.

[vovacha]

Suggested change

	version = "0.1.0"
	version = "3.1.60"

[vayesy]

Feature flags are good to have, however I think we should work on them at a later stage. There are few reasons why:

1. Audit. Even if feature flags will control which packages and pallets are installed/available, those should still be described in the runtime source code meaning they are present even if not used.
2. Having pallets present in the source code, even without actual usage of them, requires to support this source code even if it is not installed via feature flags. This looks like unnecessary overhead for unused features.

I would suggest to skip feature flags for now and start working on them just before we would release official first version.

• the audit will audit what is being built for live version. so not really an argument.

• we will always work on all pallets, either in 203489572 separate repos or in one consolidated codebase

• how to treat e.g. orml?

• feature flags are the designed way to go, it is proven in e.g. acala

• we should not fear but adopt

• we will add much more complexity maintaining many repos and keeping stuff in sync and finding working combos than having one repo containing all runtimes, nodes and pallets so we can build what we need any time.

• we really need this plan for the rollout, could be something solved in a primitive way through feature flags which we attribute to certain protocol versions or we need to build version and tag as we go and add it to the network upgrade procedure and respective voting process ( needs also to be tested )

• we already run official versions so to say, this is nothing we talk about "in the future", as we are already in the process of public release (rococo, slot auction, etc) and need to set these things up without cluttering everything up on the last mile (suggestion)

• we need to make better use of tags, they can also be experimental, development, latest, stable

the stable staging could get a complete end to end build with stuff tagged stable and matching versions.

@vasylenko-yevhen @vovacha @DarkNebula0

[2075]

should we separate builds by creating n names and folders or by tagging properly and maintaining one consistent codebase?

[vovacha]

• we want feature flags for runtimes. Make sense to me.
• we want to have not only release tags, but also somehow describe stability (experimental, development, stable). Also agree that we should somehow mark unstable releases.

we will always work on all pallets, either in 203489572 separate repos or in one consolidated codebase
we will add much more complexity maintaining many repos and keeping stuff in sync and finding working combos than having one repo containing all runtimes, nodes and pallets so we can build what we need any time.
should we separate builds by creating n names and folders or by tagging properly and maintaining one consistent codebase?

Nobody suggested changes or splitting stuff. Could you elaborate on this?

how to treat e.g. orml?

What's the context? It's an external dependency.

we need to build version and tag as we go and add it to the network upgrade procedure and respective voting process

It already works like that with the release tag except for the voting, no?

we already run official versions so to say, this is nothing we talk about "in the future", as we are already in the process of public release (rococo, slot auction, etc) and need to set these things up without cluttering everything up on the last mile (suggestion)

Could you elaborate on this? Not clear what's the suggestion about.

we need to make better use of tags, they can also be experimental, development, latest, stable

Sounds good. So far, we have only a release tag, but it's not clear if this release is stable or not.

@2075 or @vasylenko-yevhen?
cc: @DarkNebula0