morallo
commented
3 years ago @Prof-Butts answering your question in #8 about the branching strategy, what I propose is to use "master" as the main dev branch, containing the latest changes developments that work.
When you want to work in a new feature or experiment, you create a dedicated branch (basically the same you were doing), but don't change/fix anything there except the specific feature of the branch. If you see a bug or you want to improve something unrelated, you checkout master, fix it there, and then merge/rebase the fix into the feature branch.
The feature branches should try to be as short lived as possible, merging back into (or from) master often (through a PR for anyone but you), but maybe disabled with a "feature flag". In general, long-lived branches are problematic to merge.
I believe this flow would allow for a simpler collaboration, as anyone that wants to try something knows they should work on master, and send a PR against master.
Finally, when you have a stable or beta release, you create a release from master in GitHub, which implies creating a tag . You can use this tag later to create a hotfix branch if you need to release a fix without publishing a new release from master, but I don't think we need to care about this because the stable releases never get updated, right?
All this is much easier to do if the code is more modular than it is today. If all the changes from all the features are impacting the same functions, merging becomes much harder. But that is a different issue (#25).
Prof-Butts
Just a small non-issue: There are a large number of branches with no obvious "current" development version. eg, there are over 4 bloom versions - why? Should branches not be merged once complete/confirmed/working or at least labelled as archive.