So far, we have been merging simple fixes into the develop branch, but another approach could be to have two develop branches:
* develop: merged things agreed upon for the next release, things which *may* need additional testing as we move forward
* develop-stable: bugfixes only, as applied to the current release version
For many projects which use git, the master/main branch would be a "develop-stable" and people would checkout releases based on tags. Then a develop branch would be stuff like new features and updates for the next version which would be merged to master/main later on.
We have stayed out of touching the master branch since it would have conflicted with the original sourceforge git repository and only Miller touches it. Maybe this is no longer a requirement?
Even though it's not considered correct behavior, I still find it less
problematic to fully commit to changes in the main branch than to try to
maintain long twisted chains of duplicate bugfixes in both master and in some
0.52 branch - this didn't work out so well this time around (I cornered myself
into taking the GUI updates into a minor release) but, ouch, we all just have to
deal with my 1970s-vintage coding skills :)