This doesn't matter to much yet, but it would be nice once we actually have an initial release of the Rust rewrite.
The core idea behind the dev/master branch split is that all development would happen on the dev branch, and the master branch would track the latest release of hermit.
This has a number of advantages:
master would still be the default branch on github, and so the landing page/readme/in-tree documentation would all be relevant to the latest stable release. This is a Good Thing
dev then becomes the tracker for "bleeding edge" latest-and-greatest of hermit. Things on devshould work but aren't really guaranteed to, since we haven't cut a new release
with the release branch as a separate branch, we can do fun things like use CI to build and push a release binary to Github Releases whenever the master branch gets a new commit. Yay automation!
I also have no attachment to the naming suggested above. master and release would also be acceptable.
That blog post also incorporates release, hotfix, and topic branches. We already use topic branches for our dev workflow, and it might make sense to do release branches as well (once we are making releases). Hotfix branches we probably don't need.
This doesn't matter to much yet, but it would be nice once we actually have an initial release of the Rust rewrite.
The core idea behind the
dev/masterbranch split is that all development would happen on thedevbranch, and themasterbranch would track the latest release of hermit.This has a number of advantages:
masterwould still be the default branch on github, and so the landing page/readme/in-tree documentation would all be relevant to the latest stable release. This is a Good Thingdevthen becomes the tracker for "bleeding edge" latest-and-greatest of hermit. Things ondevshould work but aren't really guaranteed to, since we haven't cut a new releasemasterbranch gets a new commit. Yay automation!I also have no attachment to the naming suggested above.
masterandreleasewould also be acceptable.This is a rough description of a limited portion of the famous nvie a successful git branching model also known as Git Flow.
That blog post also incorporates release, hotfix, and topic branches. We already use topic branches for our dev workflow, and it might make sense to do release branches as well (once we are making releases). Hotfix branches we probably don't need.