Module upgrade strategy and guidelines?

[xlc]

I understand it is possible to upgrade runtime to add new features but are there any guidelines of what can be changed in the new version and what cannot be done?

For example, I suspect add/rename an Enum variant or struct field are backward compatible and therefore allowed and reorder/delete changes are not.

Also what will happen if we add a non optional config to storage, change the type of a field in storage?

Are there any resources I can have a look (maybe the codec documentation?) or the current recommend way to approach this is just doing bunch experiments and see what happens?

[gavofyork]

There are no resources to hold your hand at this point.

By upgrading the runtime, you're simply switching out the block of code that is going to be receiving extrinsics and reading storage. Other than that (and the Encode/Decode codec stuff), there's nothing special going on. To judge whether the #[derive(Encode, Decode)] of one datatype will be backwards compatible with another (earlier version of it) you'll need to look into parity-codec-derive module; for enums, I think you can safely add items to the end without breaking compatibility.

If you add a non-optional config to storage, it'll just take the Default::default() value. If you change the type of a field in storage, then it'll just be equivalent to NewType::decode(OldType::encode()). If that doesn't make any sense, then your runtime will panic and your chain will be bricked.

Current recommended approach is to understand the parity-codec/parity-codec-derive (by reading the code and tests) and how it relates to the storage macros (which is pretty straightforward).