(Whoops, sending again with correct subject line) 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? > On Oct 15, 2022, at 12:00 PM, [email protected] > <mailto:[email protected]> wrote: > > 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 :) -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
