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)?