This may be handled differently for different projects. I'd see future development come up either on feature branches or on main.mcarans wrote: ↑Sat Mar 21, 2026 8:39 pmI was curious about the best approach to use in future. AI gave this summary:
"When you fix a bug on a maintenance branch, you are working with a known, stable state of the code.Code: Select all
Source Recommended Direction Key Reason Microsoft Maintenance → Main Prevents regressions in future releases. GitFlow Maintenance → Main + Dev Ensures the fix is applied to all active streams simultaneously. Pro Git Book Maintenance → Main Simplifies the merge history by keeping main as a superset of maintenance.
If you fix on 1.92-maintenance: You are testing the fix against the exact code that will ship in 1.92.1. You know it works in that environment.
If you fix on main first: You are testing against the latest development code (which might have SDL3 changes, new dependencies, or refactored logic). When you try to bring that fix back to 1.92, it might not even compile or could introduce a "regression" because the underlying code has moved on."
I think what we should try to do in future is for all devs to agree on a merge strategy but even before doing that we really need to sort out the whitespace issue. The Obj-C source code has random extra tabs at the end of lines or on otherwise empty lines and that makes doing any changes to it more painful than it need be because you need to try to preserve the erroneous whitespacing otherwise you get loads of changes. It also makes merging more difficult.
If we find out a release has a bug we do not want to accept (and tell people to wait for the next release), that one gets fixed on the release branch.
As only bugfixes would go into the release branch it is arguable whether the diff can be reapplied to main or the same fix needs to be applied differently, if at all. So this is a case by case basis.
However I'd even argue whether the many changes we did on the release branch were necessary and whether the problems could have been spotted earlier. One reason for the late spotting was the availability of the would-be release. Now that the release branch emits prerelease builds accessibly for the public such testing is vastly enhanced.
Plus we still need to verify why a directory like AppImageHub takes metadata from prereleases (where we have still not added any such metadata). I'll try to get an answer to this question, not to talk about a fix.
