Design a friendly, easy-updatable/iterable system

Hi. I’m Xavier from Darwinia.

I have been working on the Polkadot ecosystem for over three years.

I did so many updates.
So, I got some experience.
I know what I should do during an update.
It’s so hard for a new team.
And it’s still a little hard for me, especially as we integrate more components.

In the past, we only had Substrate upstream dependency.
Now, we have Substrate, Cumulus, Polkadot, Frontier, Parity-Bridges-Common, and Moonbeam, these upstream dependencies.

I need to review every commit of those repositories and check if it affects our code.

And I made a tool to track the updates:

This tool is good but not good enough.

  1. It can only list the commits/pull requests and do some categorisation.
  2. Different repositories have different labels

So, I hope all repositories should have some basic/must-have labels. We can redesign the GitHub labels.

How do you guys do the Substrate update? We can share our experience here. :grinning:

Moreover, what else can we do to build a friendly, easy-updatable/iterable system?

9 Likes

I have been involved in crafting the release analysis we have been publishing in the forum, where we try to cover PRs that are relevant for builders, obviously there will be very concrete scenarios where different PRs might be relevant on different levels for various teams.

But I wanted to bubble up the new labels that are being included, so far in Cumulus repo.

That has been an effort led by @joyce (big shout out!) and I am positive that these would make it much easier for teams to track changes and keep projects up to date with their deps, and for me and my colleagues to create the release analysis in a more efficient manner.

2 Likes

Also want to throw https://polkadiff.parity.io/ in there as an underrated tool for keeping up with Polkadot changes. Your work in Subalfred also seems quite impressive!

I am well aware that keeping up with these changes has been hard for the ecosystem and I see two aspects to it:

  1. Polkadot and Substrate move fast. Should we slow it down? While this has been tabled here and there, I would say no. The whole ideology of Substrate is upgradability. Moreover, technical excellence has been one of the strong points of the Polkadot ecosystem, attracting many developers. I think by slowing things down too much, we lose these aspects.

  2. Having more formal structures around labels, change-logs, and releases, making it easier to keep up with the same amount of changes. I am very much in favor of this and seeing the new structure in the Cumulus repo, I hope @joyce takes big steps in this direction.


As a side note, I suggest your rename this thread to “Keeping up with Substrate updates!” or something similar as the original name does not resemble with the content to me.

1 Like

I do not think we should slow it down.

However, we should make it easier (perhaps even seamless) for others to upgrade.

What are the bottlenecks/pain-points to upgrading? And how can we improve this?

We definitely need better communication and need some tools to improve it.

A recent example from Acala: When using this interface "/blocks/:number", this code is returned with a 500 error · Issue #1165 · paritytech/substrate-api-sidecar · GitHub

Due to the Weight V2 change, the transaction payment API was broken. The error was found and fixed in a later release without any noticeable labels / notifications / backports.

Then Acala upgraded to the buggy Substrate version with this bug and we only noticed this due to user report as we don’t use substrate-api-sidecar ourselves.

2 Likes

In case anyone has not seen it, I believe the following suggested RFP for UpChain is relevant (seeking additional feedback)

Please note:

  • The use case is (almost certainly) narrower than what you have in mind; better to start small and iterate out/up.
  • Protocol changes very likely would be required