Release 3.0.7

[pgervais]

Main ticket to track the status of the 3.0.7 release, and the decisions that were made during the process, for future reference.

[pgervais]

I created release branches for 3.0.7 in both zynaddsubfx and mruby-zest-build, because I expect there will be some minor fixes necessary in the build system, in particular for Mac OS. I don't want to block the work on https://github.com/zynaddsubfx/zynaddsubfx/pull/221, so having a separate branch makes it possible to work in parallel.

https://github.com/zynaddsubfx/zynaddsubfx/tree/release-3.0.7 https://github.com/mruby-zest/mruby-zest-build/tree/release-3.0.7

My plan is to add a tag with the version number once we decide to release, and to cherry-pick on master whichever fixes are relevant.

I will also add such a branch in zyn-fusion-build, after I've made some modifications to make it possible to specify which branch to clone for the zynadd and zest repositories - so that the '3.0.7' commit in zyn-fusion-build actually compiles zynadd release 3.0.7 instead of the git HEAD.

[pgervais]

I'm treating https://github.com/zynaddsubfx/zynaddsubfx/issues/246 as release-blocking, because it breaks the build on Windows.

[pgervais]

A short update about the status of the release so far:

• Linux: Compiles fine with fltk/ntk/zest UIs. The standalone binaries run, I saw some weirdness with VST2 and LV2 plugins in Ardour but it's likely my ignorance that is the cause here. I'll look harder.
• Windows: doesn't compile (see previous message)
• MacOS Intel: not tested yet
• MacOS Apple silicon:
  • the standalone binary compiles with the fltk UI, with this patch: https://github.com/zynaddsubfx/zynaddsubfx/pull/247. I am treated the NTK and zest UIs as not supported for the time being.
  • The Zynaddsubfx plugin does not compile maybe because of a lack of support in DISTRHO for Apple silicon (see below)
  • All other plugins compile. I haven't tried running them yet.
  • Zynaddsubfx and rtosc tests compile and run, but three of them fail: test-port-checker, UnisonTest, MessageTest. I haven't investigated yet.

This is the compilation error I get on MacOS Apple Silicon:

Compilation failure for ZynAddSubFX_lv2_ui
[ 85%] Linking CXX shared library lv2/ZynAddSubFX_ui.dylib
Undefined symbols for architecture arm64:
  "DISTRHO::getDesktopScaleFactor(unsigned long)", referenced from:
      DISTRHO::UI::PrivateData::createNextWindow(DISTRHO::UI*, unsigned int, unsigned int) in DistrhoUIMain.cpp.o
ld: symbol(s) not found for architecture arm64

@falkTX Is that missing symbol error expected?

[falkTX]

might be. until we deal with the dpf update on the main zyn repo we cant expect DPF stuff to work proper. previous attempts of non-linux builds were always very hacky.

the PR with the DPF update (and then reusing DPF CI stuff for testing) is a step to ensure win/mac/linux plugin builds work proper.

[pgervais]

A short update. Using one of github's MacOS builder I ran a compilation of zyn on Mac Intel. It failed with the exact same error as on Mac Arm.

This means that zynadd standalone with the fltk interface can be compiled (and runs), but the plugin version doesn't compile. Given the current refactoring, I see two paths forward:

• we give up on the macos plugins for version 3.0.7 and publish the release with this caveat.
• we give up on pushing the 3.0.7 release before the DPF refactoring.

I would be in favor of the second one. @fundamental what's your take on that? It looks like the DPF change is getting closer to completion. Is it worth waiting?

[pgervais]

Other problem: Windows cross-build is broken. See my comment on https://github.com/fundamental/rtosc/commit/96eaa76fb8292e05b0b8ce42e8c5741c5b48efab @fundamental @falkTX

[fundamental]

I'm fine with this release having issues with MacOS since that's been the case for the last several, it wouldn't be a bad thing to have a release finalize the DPF changes (last time I checked there were a few regressions, but some of those may be resolved now). As per the windows cross build, something is breaking liblo pathing. I think there was a recent patch for using pkg-config in that environment which may be the source of the regression 8a12c705f89535cf5c416e539a8f57aac7799bfa