moonbeam-foundation
Standard for the git branches in Moonbeam and Dependencies
What does it do?
This is a proposal of agreement for the management of the git branches and their naming. This proposal must first be discussed and validated internally on the substance.
What important points reviewers should know?
Is there something left for follow-up PRs?
What alternative implementations were considered?
Are there relevant PRs or issues in other repositories (Substrate, Polkadot, Frontier, Cumulus)?
What value does it bring to the blockchain users?
Checklist
- [ ] Does it require changes in documentation/tutorials ?
I like this idea. I would also like to add the suggestion that our
masterbranch follows our dependencies'masterbranches. This is already how polkadot and frontier follow Substrate, and it is how cumulus follows polkadot and substrate.This would allow us to immediately use PRs that we get merged upstream, without having to leave our work open, blocked, and getting stale for a while.
This would also move the job of choosing a specific polkadot version branch and stabilizing moonbeam to the release process. That keeps it out of the way of on-going development.
But the opposite is true too. You wouldn't be able to merge your PR if no-one has updated master to latest substrate ? Also it means maintaining our dependencies (like frontier) to target master too right ?
You wouldn't be able to merge your PR if no-one has updated master to latest substrate
That's already true, and I agree it is still true. The idea is that Substrate updates could be small and frequent, and you could follow up almost immediately.
it means maintaining our dependencies (like frontier) to target master too right
Yes. Polkadot and Cumulus (including nimbus) have been doing this for a long time. Frontier recently started doing this when Wei finally admitted that Substrate's releases were too broken to use. The only place we would have to make a change would be in crowdloan rewards, which would help unblock two currently-stuck PRs.
Another proposal related to branch management.
I was noticing the difference in complexity and effort between #786 and #797. Both of these PRs have the sole goal of cherry-picking some commit from Substrate into our branch. The first PR took a lot of manual branch creation and updating work, while the latter just required changing Moonbeam's cargo.lock.
The key difference is that in #786 we had to create our own branches in substrate, polkadot, etc because we had previously been following branches controlled by parity (polkadot-v0.9.9). Whereas #797 was much smaller because we already had our own Substrate branch and we just had to push a commit to it and update Cargo.lock.
This gives me the idea that in @librelois's plan, each of our moonbeam release branches should be accompanied by a dedicated branch in Substrate, Cumulus, Frontier, Polkadot that we control. That way when we need to make a hotfix, it is as simple as in #797.
@librelois Do you think we could start to finalize this PR and merge it ?
I decided to strongly simplify these conventions, to stick to what we actually did to hotfix the 1500 runtime.
And anyway if conventions are too complex nobody will apply them correctly...
The sense of the old conventions was to have the CI test the patch on the hotfix branch, but now that the CI is triggered by a push on any perm-* branch (before it wasn't), we can afford to do cherry-picks, and the CI will test the cherry-pick well.
Yeah !! I'm sure if we look more in the list we might find some that would set a new record too :p