Setup next-moc branch

[rvanasa]

Adds CI workflows to set up the next-moc branch in the same way as the previous base library repository.

Progress:

• Documentation
• sync CI workflow

Splitting into a future PR:

• Run tests using master branch of motoko repository for next-moc

[github-actions]

✨ Documentation preview for 9628bff:

https://dfinity.github.io/motoko-core/pull/335 (source code)

[crusso]

Looks good! I guess we also need to actually create the next-moc branch (and then get motoko to pull from that).

[christoph-dfinity]

Spotted a bit of master -> main churn in the Release.md instructions. Might be worth grepping for master in case I missed any occurrences.

[Kamirus]

But do we actually need a separate branch now?
Having both main and next-moc has several drawbacks, like non-linear git history which results in horrible git history, need for automatic updates of both of them, general problems of having 2 main branches that are most of the time identical.
Can we avoid these for now? How frequent we are going to have incompatible changes between motoko and motoko-core? When was last time next-moc on the motoko-base repo was actually useful?

[rvanasa]

Spotted a bit of master -> main churn in the Release.md instructions. Might be worth grepping for master in case I missed any occurrences.

Thanks! Checked and found that all of the other references to master are in the context of other repositories.

But do we actually need a separate branch now?

This is a fair point. I suppose we could always set up next-moc in the future if there's a clear need for it. I like the idea of initially keeping it simple.

[Kamirus]

next-moc is only needed when we introduce breaking changes in the motoko repo. So that we can pass the CI on the breaking change PR. After releasing the breaking change (creating a new version of moc), the motoko-core can be updated (on the main branch, using the new moc) and next-moc is no longer needed (I'd remove it at this point).
I'd always keep the main branch as the only main branch with linear git history, no arbitrary merges like on the legacy motoko-base.
next-moc is basically an implementation detail of the motoko repo (needed for its CI) leaking into motoko-core repo.
This is fine as a temporary branch: temporarily used in the motoko repo for the CI before the new moc is released and motoko-core can be updated.

Breaking changes are rare. If we ever plan one, then we can:

• create next-moc branch on motoko-core and make it compatible with the unreleased moc
• in the motoko CI temporarily use next-moc instead of main
• continue development on:
  • motoko repo: add new PRs that will be included in the new breaking changes moc version
  • motoko-core repo: new PRs on the main branch would need to be fixed later when updating to the next moc
• note that in this point in time main and next-moc branches cannot be synced as they contain incompatible changes
• release the new moc with breaking changes
• update motoko-core to the newest moc, make a PR that merges the next-moc to main.
• revert to using main in the motoko CI
• next-moc is not longer needed, no need to keep updating it, nor merging between main and next-moc

[ggreif]

My instinct is that until core is declared the preferred one, it can lag a bit behind moc, so let's use base:next-moc for moc-latest CI testing and core:main as a nightly for moc. When a moc feature is released, we can forward-port from base to core rather quickly.

UPDATE: dfinity/motoko#5317 now (rather: will) tests motoko-core nightly.