2025-05-15 Platforms & Builds Module Meeting

Meetings
1

Attendees

  • Anthony Roberts
  • Sebastian Parborg
  • Thomas Dinges

Notes

Blender 4.5 library updates

  • #136540: Library changes for Blender 4.5 LTS has a new overview table in the beginning summarizing all pending updates.
  • Meeting agreed on pushing updates to main and work on them iteratively. Thomas will poke people to make sure the remaining PRs land.

Future deadline to request library updates

  • Starting with Blender 5.0, library updates have to be requested in the first few weeks of the release cycle in Alpha. The deadline is one week after the prior release is published.
  • The corresponding library update tasks will have a table, in which all requests are collected.
    • Updates can be added there by every active developer.
    • New libraries have to be requested and be accepted by the admins first. See New Dependencies

Linux

CMake

Meeting Info

This is a video chat meeting to plan and discuss development for the Platforms & Builds development module. Any contributor (developer, documentation writer, …) working on this area in Blender is welcome to join and add proposed items to the agenda.

For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.

2

It’s up to platform maintainers how they want to organize themselves, but for reference I think the most efficient way for everyone is to do this:

  • Create a lib update branch for each release
  • Land pull requests in that branch, with only superficial review from maintainers, or no review for simple version bumps. No need to build anything.
  • When the date for updating libs comes, maintainers test building the branch and push any required fixes.
  • Commit updated files to branch in blender/lib-* repo and make blender/blender PR for testing.
  • Merge changes into main once all platform maintainers are ready.

This way maintainers only have to spend significant time once per release, and landing PRs is not blocked by each platform maintainer testing it. That reduces context switching overhead for everyone.

When we did this in the past, in my opinion it worked better than the process we have now where every platform maintainer is on every PR, and expected to test building it.

1 Like
3

i gotta agree, having an update cycle with either an llvm , dpcpp, or USD update in it is devastating to my already limited time, if i just tested one of those and a quick lets say freetype update comes in, there’s no quickly testing that, that would normally build in under a minute, but that is just not gonna happen if llvm starts a rebuild cause it’s now back to its old version.