ZDoom

I mix between command line and TortoiseGit. For the simple operations command line is faster, but as soon as it becomes necessary to mess around with the tree it'll become awkward very quickly.

Actually, I use the command line too. The only guis I use are "git gui" and "gitk".

And because I use the command line tools I don't think about such issues as how branches cross each other.

See, and with a good GUI tool a cherry pick is no work at all. Just select the commit, click 'cherry pick' in the menu and press 'OK'.
Maybe that's why Randi and I don't think about such issues...

Because I use the command line (on all platforms) so the following is much easier:

I normally did all release tags in GZDoom off the mainlines. That way they didn't become a problem. (i.e. when ready, branch off, change the version number, tag the new commit and delete the temp branch.)
Comparing cherry-picking with constant merging, what does it matter? You got the same number of commits anyway and the two lines remain clean. I'd avoid merging between them as much as possible. Please don't forget that for GZDoom at the moment there's two master and two maint branches so the less they affect each other the better.

And what makes you think that double-committing is more work? A cherry pick is just as easy as a merge.

Yes, but that's solvable by just making an empty commit for the release tag. In my opinion that seems like a better option than double committing everything since that involves more work.

Blzut3 wrote:By the way, what's with the double commits? Are we not merging maint into master anymore?

If I recall correctly, if we merge maint into master, running git describe --tags from master will pick up the tag from maint, since the path to it is shorter than the one earlier in master.

I'd personally wait out tomorrow at least. Just do the release before Friday as I might be away next weekend.

By the way, what's with the double commits? Are we not merging maint into master anymore? The error in the 2.7 branch was an accidental master to maint merge. Graf's commit ordering looks like he committed to the wrong branch and then cherry picked, but yours look intentional so that's why I'm asking.

2.8.0.½-Redux-FinalMix

You could always do a 2.8.0.1, in case something else comes up...

It appears you fixed some surprisingly serious issues in this regard. I'd say 2.8.1 being released now wouldn't hurt.

Fixed. Now do I do a re-release right away or wait a few more days for 2.8.1?

FMOD 4.36 was chosen for the release because it's the last version with pre-XP support, but it's not one I actually tested on until now. When I decided to dig into what I was doing wrong to muck up sound on post-4.26 releases, it was at 4.38, so I just skipped over 4.36.

I'll have a look at it later. I'm out of time now. But the logging version of FMOD (fmodexL.dll) works fine.

I have this feeling that the changes to fix reverb support in new versions of FMOD have broken the specific build Randi used for the official build. At a guess, the dsp buffers fall apart causing FMOD to fail. You have have two buffers playing at once, the second at a very latent time, or the reverb just fails entirely.