Repository navigation
v0.11.0 #2038
Description
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? Everything apart from E1.37-4 is now in, but I think that will have to wait...
- 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 distto 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. - 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
Metadata
Metadata
Assignees
Labels
No labels
Activity
peternewman commentedon Apr 5, 2026
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 commentedon Apr 7, 2026
@peternewman when you have a moment can you try updating the
0.11.0-pre-releasebranch and let's see if CI passes (except for forky and sid)?peternewman commentedon Apr 18, 2026
Out of interest, why do you think forky and sid will be broken?
DaAwesomeP commentedon Apr 18, 2026
IIRC they need all the pre-C++11 compiler fixes that @aroffringa will merge for v0.12.
peternewman commentedon Apr 19, 2026
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 commentedon Apr 19, 2026
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 commentedon May 20, 2026
Hey @peternewman and @aroffringa, how are we progressing? What's left for v0.11.0?
aroffringa commentedon May 21, 2026
As far as I can tell we're ready to release. Shall I make one @peternewman ?
peternewman commentedon May 30, 2026
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-extensionfixes 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 commentedon May 30, 2026
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.
DaAwesomeP commentedon May 30, 2026
I don't see anything in the v0.10.10 or v0.11 milestones list that need to block it (in my opinion). I think there are some there that will be essential for v0.12, but we can look at that after we get v0.11 out.
peternewman commentedon May 31, 2026
Should we at least move those to 0.12 then, so we don't risk missing them? Previously I've generally tried to go for a clean milestone at release time, by either resolving or reprioritising as appropriate.
DaAwesomeP commentedon May 31, 2026
Yes, they should move over. However they should also be re-evaluate by priority. Some of them might make sense to go back to 0.future.
DaAwesomeP commentedon Jul 10, 2026
Hi @peternewman checking in once again. How can we help get this release out?
peternewman commentedon Jul 12, 2026
Sorry work and life have been busy, however the good news is here's a task we can all collaborate on (and do a bit more piecemeal, which has been part of the challenge for me personally). I'm also really regretting the fact we didn't do it as we went along, as it's made it a lot more arduous. Anyway it's updating NEWS. See #2060 but as mentioned in there I'd suggest if people propose changes for the PR numbers to turn them into a NEWS summary line, we can then merge all those proposals and then re-organise by section as appropriate...
peternewman commentedon Oct 13, 2026
If someone can review and merge #2081 then we might be good to go.
I half wonder if we should merge #2077 and my related #2080 but I've not heard back from the reported and I'd be happier if we can validate reproduction first with the improved tests before we merge the fix...
After at least the first bit, does one of you two want to have a go at cutting the actual release?
aroffringa commentedon Oct 13, 2026
I've approved #2081, but I'm not allowed to merge it without the tests passing.
I think #2077 can wait.
If you want me to open a new release on github for v0.11.0 (after #2081): sure, happy to do that.
peternewman commentedon Oct 13, 2026
Ah I didn't realise, I guess we should fix that, or better yet get ourselves back to lint clean, which I've taken a bit of a move towards in #2081 by removing the retired LTS Bullseye builds.
Fair enough
Yeah that would be good. You'll need to do the version number bits above first before we cut the release on GitHub, and then upload our own tarball after we've released to add to the GitHub release, plus the various comms etc...