Continuing the discussion from HTML code no longer saving in a dashboard:
@TrystanLea, this is yet another example that shows that there is a very real need for a dev branch on the emoncms repo that @emrys can use.
Pulling in ‘test’ stuff from a branch on a different repo is far more difficult than simply switching branches on emoncms repo. It is also much easier to reset at update time if necessary.
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.
Yuck!
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, @emrys @glyn.hudson 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.
Sorry a bit flippant.
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.
I’ve created an issue here to help with tracking: Feature request: switch between git branches from emoncms admin UI · Issue #1501 · emoncms/emoncms · GitHub