v0.11.0

[DaAwesomeP]

Release v0.11.0

Notes for building: 

• Before testing on each system remember to update (apt, ports etc.)
• From within the ola directory, you can get the compiler version with:
• Make sure you run ./configure --enable-rdm-tests --enable-e133
• Make sure you have all the dependencies installed (libusb-dev, libftdi-dev, liblo etc.) |  

Maintainers should be able to edit/check things off. If you check something off, please add your @ at the end of the line.

• Create a new issue for the release version - @DaAwesomeP done
• Test on as many platform / arch / compiler combinations as you can
• Make sure you have automake >= 1.15
• Check for any new Debian bugs
• Pull in the latest PID data - @peternewman is currently refreshing this via Add new PID data from E1.20-2025 rdm-app#321 and Autoupdated manufacturer data rdm-app#324 but very happy if someone else wants to try the import process to get familiar with it?
• Check a few copyright dates and update if necessary - Done in Update 0.10 based NEWS #2057 we've got until the end of 2026! 🤞
• Check the NEWS file one last time - Can be done collaboratively in Add 0.11 news #2060
• Pull in the Debian changes - @DaAwesomeP this is good for now once we merge Update Debian Package Services and Config Directory #1855. There are some minor man pages things we can table for now and the rest are compiler related things to fix in v0.12.0
• Increase the version number & commit <- this is the release
• Tag the release commit with the version number
• Run make dist to produce a tarball
• Upload the tarball
• git push --tags
• Branch the release off
• Protect the new branch including status checks on GitHub
• Close the existing milestone
• Create a new milestone for the next point release
• Post on the mailing lists (bcc the other lists), G+, Twitter, FB etc.
  • open-lighting-announce@googlegroups.com
  • open-lighting@googlegroups.com
  • rdm-testing@googlegroups.com
• Email people to make debs
• Possibly update the RasPi image
• Update Macports
• Make a new doxygen snapshot
• Update NEWS with a placeholder for the next release

cc @aroffringa @peternewman @nomis52
Result of #2035

[peternewman]

I've started on a branch which has everything good without the C++11 breaking couple of commits that got dragged in, which is currently here, unless someone has a neater way to do it (having tried doing reverts before it just got very messy/confusing, hence an alternative approach):
https://github.com/peternewman/ola/tree/0.11.0-pre-release

[DaAwesomeP]

@peternewman when you have a moment can you try updating the 0.11.0-pre-release branch and let's see if CI passes (except for forky and sid)?

[peternewman]

@peternewman when you have a moment can you try updating the 0.11.0-pre-release branch and let's see if CI passes (except for forky and sid)?

Out of interest, why do you think forky and sid will be broken?

[DaAwesomeP]

IIRC they need all the pre-C++11 compiler fixes that @aroffringa will merge for v0.12.

[peternewman]

IIRC they need all the pre-C++11 compiler fixes that @aroffringa will merge for v0.12.

Well they seem to be fine on the older version with e.g.:
https://github.com/OpenLightingProject/ola/actions/runs/24635061341/job/72028915747

I assume the issue would just be around having a suitably old protobuf etc to compile against...

[aroffringa]

The fixes shouldn't be necessary as long as the compilers are set to compile in the right C++ mode. However, the libraries generated might be inconsistent when compiled against newer software because of ABI changes in the standard. I do compile glight against it in C++17 mode without issues other than the sea of warnings, but glight uses only a small subset of the library so it's not a guarantee. But all the more reason to release quickly and move on ;).

[DaAwesomeP]

Hey @peternewman and @aroffringa, how are we progressing? What's left for v0.11.0?

[aroffringa]

As far as I can tell we're ready to release. Shall I make one @peternewman ?

[peternewman]

Sorry for being so rubbish at replying. I also still need to finish writing the changelog.

Also I think we ought to get a fix for this in, as currently (according to the CI at least) we don't build on Clang! Just adding -Wno-error=vla-cxx-extension fixes it on my CI tests, but then breaks the GCC build as it's a Clang specific flag, so we need some Autoconf magic to only apply that flag to Clang builds. I think we can drop the other stuff in that build as there were just far too many places to apply it as a pragma based fix.
master...peternewman:ola:0.11-plugfest-fixes-cpplint

We should also do a quick triage of at least the "bug" issues from the current milestones to work out if they're critical enough they need to be fixed in 0.11 or 0.12, or can be pushed into the long grass of 0.future and attempted at some point in the future. I know @DaAwesomeP had done a great job of looking at moving some of these already.
https://github.com/OpenLightingProject/ola/milestone/21
https://github.com/OpenLightingProject/ola/milestone/9

[aroffringa]

When I compile with -Wno-error=vla , the issue is solved in clang. That option is also supported by gcc.

FYI, I've done a compilation of the master branch on my arm-based odroid machine (using gcc), which works without issue.