Takeaways from feedback for the Blender 4.3 release

Hi everyone,
after the 4.3 release, developers took a bit of time and reflected on how things went. The following is a summary of that feedback with clarifications what we expect.

Documentation & Release Notes

  • Document changes and new features as soon as they land
    • It is the PR authors responsibility to document the change in the release notes and in the manual. If that fails it is the responsibility of the module to ensure this work is done.
  • Add visual examples for bigger changes to the release notes (screenshots, videos, performance metrics…)
    • These can be done later in the release cycle but not later than at the end of Beta. It’s again the responsibility of the PR author or the module.
  • Highlight compatibility changes (deprecations, API changes…) more prominently, especially in the final release notes on blender.org.

Projects

The following is mostly applicable to the project planning stage where we’ll try to be better, and want to help project leads with the scoping:

  • Split larger projects into smaller deliverables if possible
    • This way continuous testing/fixing can be done and issues can be spot earlier in the development process
  • Only land projects in main once they are ready and stable
    • Projects should have their own Alpha, Beta, RC phase and not land in main before they are ready
    • Also do not merge projects that have a long known to-do list, finishing all of these shortly after merge is difficult and likely result in major known issues that exist for the duration of several releases then
  • Reserve project team resources after a project lands to stabilize it
    • Be able to fix and work on all incoming bug reports
  • Take high level user workflows into account when designing features
    • Ask for user feedback on devtalk or at least consult module artist members when changing workflows

Communication

  • Promote Beta and RC builds more on blender.org and social media to get more testing and bug reports

Tests

  • At least ensure high severity issues have regression tests. Ideally even refactors needs to be covered with tests (before the refactor!) and that is where we want to go in the future.
    • Improving test coverage will help avoiding similar issues in the future
  • When doing changes (new features, refactors etc…) asses the project risk based on test coverage within that area (Example: Geometry nodes or Cycles have broader testing than e.g. UI)

Schedule

  • Take availability of developers into account for release planning, understand that for the third release each year there is less available time due to holidays, Blender conference etc
  • Add more explicit milestones to the schedule like
    • UI Freeze (Beta)
    • Python API Freeze (Beta)
    • Translation Freeze (RC)

Thanks,
Thomas

31 Likes

Having beta and RC builds more accesible and visible could help a lot with finding bugs earlier, instead of just relying more on media promotion i’m thinking more of like adding direct links into the blender UI itself. For example adding buttons “Get newest version” and “Try upcoming features” to the splash screen, about blender or help menu could improve accessibility for a lot of users who aren’t directly interested into the development itself.

6 Likes

Just to clarify with a concrete example: For the upcoming 4.4 Beta, your suggestion would be having the 4.3.x releases expose your suggested links / buttons?

Basically yes. It would only work for 4.5 versions and upwards if added to 4.4 before stable release.

And to clarify (i think i’ve written it a bit too complicated): Add a link to the UI sending users to Blender Builds - blender.org or to a designated page only featuring beta/rc builds.
Idk how many users even know about alpha, beta and rc builds and where to get them. On steam you guys have beta channels quite easily accesible via steam client, but for the regular version users would actively have to go to the download page and scroll all the way to the bottom.

Just a suggestion, probably can’t hurt too much as on the about menu also shop etc. is linked.

2 Likes

Just to add my 2c to this part. I wonder if the wording is not ideal either.

On the bottom of that download page, it’s all called ‘Experimental’. So on top of it’s own page and direct links within Blender, etc, I think it would be better to call it all what it is, Beta or Release Candidate.

People are pretty well versed in those terms and know what they mean.

While in many ways, what adds extra confusion is that there really are Experimental builds of Blender, where totally independent possible future feature testing goes on (the current NPR Prototype being a prime example).

Does that mean all individual pages, or a single page with better wording/sections and then how and where it’s all pointed from or too for better visibility at times, etc could of course all be up for debate and maybe worth a much fuller overall discussion.

3 Likes

Speaking of renaming/reordering the test builds on the web for less confusion and better discoverability, i want to push an idea from right-click as i think it suits the discussion: Blender Hub - Central manage place and Blender Hub - Blender downloader, which would esentially be the same as the unity hub where you can manage blender installs, check for updates, get preview builds etc. Currently if you don’t go the way with package/app managers (like steam) you’d have tons of installers and beta zips for testing lying around in your downloads folder. Having a simple (official!) manager hub for that would be great as it would allow comfy testing for all non-self-builders as well.
If BF decides to make blender a more closed and accesible environment, this could maybe be a good fit for a GSoC project (UI-Design and implementation)?