Migrate to an alternative branching strategy

[scroix]

@justparking There are a bunch of open-source projects with limited maintainers that serve as an example for good branching strategy.

https://github.com/mrdoob/three.js

• 100k stars, 35k forks, 40k commits
• 1 - 2 maintainers

https://github.com/tailwindlabs/tailwindcss/

• 207k stars, 34k forks, 3.5k commits
• 1 maintainer

https://github.com/vuejs

• 78k stars, 3.9k forks, 5k commits
• 1-2 maintainers

The strategy is essentially the same in all three of them.

• A main or master branch contains the latest stable release
• A dev or next branch for features and bug features by external contributors; crucially, this is often the default branch.
• There are sometimes release branches to be used as a staging for final testing (e.g. 24-hours soap dish timing based tests), bug fixes and a chance to update documentation before going to main. The benefit, I assume, would be to allow continued development whilst locking off the latest commits from dev before a release.

[justparking]

I think that'll work well.

Have you consider how we might work on a particular feature/update collectively?

For example, your PR - https://github.com/scroix/nodel/tree/feature/introduce-junit-testing - if I found a little typo, how would I go about correcting it?

I just tried to update your branch and hit this obvious hurdle:

So that can work i.e. a fork is done and then another PR can be created, however means all updates have to be done via the PRs no matter how big or small the update.

Is there any other way of doing this without moving from user-based repos to central ones: e.g.

• :scroix/nodel/introduce-junit-testing vs
• :museumsvictoria/nodel-dev/introduce-junit-testing?

[scroix]

I'm not sure a dev-repo is necessary. You should be able to edit these PRs.

It's a little weird though - the PR exists as separate branch. You can either

1. Check it out with a specific reference to the PR origin git fetch origin pull/$ID/head:$BRANCHNAME (as described here)
2. Use GitHub's CLI/GUI to check it out. gh pr checkout $ID (as described here)

[justparking]

OK, no worries. I think I was able to update a PR of yours via the git tools and it actually worked. Perhaps my method of doing it directly in github treats fork/branch permissions differently.

[justparking]

I've just implemented this:

A main or master branch contains the latest stable release
A dev or next branch for features and bug features by external contributors; crucially, this is often the default branch.

No when the repo is cloned, dev is the default.

And new PRs will target dev

[scroix]

I see this - It looks good. There was a bunch of old branches pruned too! 💛

I went ahead and updated my pending PRs to reference master as the "release" branch when building binaries as well (15b6416).