Yes we shouldn’t really be expecting users to try changes in this way. Either merging to master for testing or a dev branch if really needed here would be a good idea - we also need that branch switching feature within the emoncms UI as requiring command line for this is not ideal.
I agree except it is only a name, the real master branch is “stable”, “master” is essentially a pre-release dev branch where potential code for release is staged. All sizable dev should be done in it own feature branch until it is complete and tested, at which point it’s merged into the development/staging branch (called “master” in emoncms repos) and thoroughly tested before being released to the master branch (called “stable”). By doing all dev in one branch regardless of name, either you cannot merge feature B until feature A is finished or feature A gets dragged into emoncms just because we want feature B merged.
The enf result would be the same, there would be a single branch for the released code and another branch for the staged fix/feature once we are at the point of asking a user to test. we wouldn’t ordinarily ask a user to switch to a feature branch unless they were a developer or very keen tester. So in most cases there just needs to be a single 2-position option (dev-mode on/off), stable/master, this could be carried on throughout emoncms and it’s modules, either you run safe or you run cutting edge and switching between them should be easy and possible to do on the fly. updates should pull in both branches.
Sorry yes I do agree the feature should be tested internally prior to merging to master. At the moment the way it works is that we often have a feature branch - some times only a local feature branch, @email@example.com and I will test that, then we merge to master for a second stage of testing and then ultimately if all is well, the master is merged to stable. Each stage increases the audience.
I think my point is that where changes have been made for a user, and they are asked to test them, it would be useful for there to be a branch that enables that. Master is used by a number of people and merging what is in effect un-tested changes could have negative effects. It would, I feel, enable quick fixes to be created where necessary.
Dev - relatively un tested fixes/development - potentially unstable changes but available to all
Master - pre-release - stable changes
Stable - Tagged releases.
Not everything would need to pass through dev, but a ‘fix’ that is not tested shouldn’t be merged to a mainstream branch IMHO.
The key thing for me is to offer a simple route for users to test fixes. The ability to switch branches via the UI would be useful, but it needs to be selective by Repo I suggest .
Also, I’d like to see the merges to master happening more often. I like the Home Assistant weekly cycle but that is a bigger project. Stable is currently 52 commits behind master and the release versions are completely out of kilter. Last ‘release’ was Nov.