main vs development branch

[angerman]

As we are now having more and more users, we need to be a bit more cautious about breaking main.

As such I suggest we start having a develop branch, and make main highly protected. Only merge to main when an extended CI suite has passed from develop?

@hamishmack @yvan-sraka @andreabedini thoughts?

[yvan-sraka]

What about using main as an unstable track, but rather inviting users to checkout to a latest branch that points to the latest release tag? (and so define some lightweight release process)

[hamishmack]

We should add the branch to the ghcr references too (currently I think the GitHub actions just pick up the latest version of the ghcr files).

[angerman]

What about using main as an unstable track, but rather inviting users to checkout to a latest branch that points to the latest release tag? (and so define some lightweight release process)

That makes the nix develop command mor hairy as you need to embed the latest then. Id rather keep the nix develop github:input-output-hi/DevX working. Which means that needs to be the default branch.

[angerman]

We should add the branch to the ghcr references too (currently I think the GitHub actions just pick up the latest version of the ghcr files).

I think I changed the rules so that only the main branch triggers builds. And other branches need manual triggers.

[andreabedini]

The current wisdom seems to avoid long running living branches like develop. I guess we can find a way to merge into main only when tests pass? Or, if "test passing" is not enough to give us confidence, we can tag releases (and pre-releases perhaps).

[angerman]

I like this idea of auto-merging develop into main (or call it production), whenever automated checked on main or develop or what ever the primary development branch is go green. 👍

This can be completely automated with GitHub action workflows, so it should be rather painless and give us some piece of mind that stuff still works.