-
Notifications
You must be signed in to change notification settings - Fork 536
Description
Is your feature request related to a problem? Please describe.
Bambu Studio regularly ships config updates (machine, filament, and process) via the built-in updater. Those configs are clearly versioned internally, but there’s no public record of what actually changed between updates. It isn't clear if those config changes end up in the next version of Studio either; there's at least some period of time where it's not possible to see what changed easily.
When print behavior changes after a Studio config update, users have no way to tell whether they’re seeing:
- a slicer bug
- a config change
- or something they did wrong
That ambiguity turns into a lot of “this was working before the update” issues with very low signal.
Describe the solution you'd like
Concretely: publish release notes and/or diffs for config updates, even at a high level. This could be:
- a GitHub repo of the versioned config outputs. Releases with changelogs would be great.
- published changelogs on the wiki, similar to the Studio or Firmware Release notes pages.
Describe alternatives you've considered
- Turning my Studio config folder into a git repo so I can
git diff headafter config updates - Reverse-engineering changes via trial prints
Both are pretty brittle and push a lot of detective work onto users.
Additional context
This would be a net win for support and triage, I think.
If users can see “PETG flow defaults changed for P-series” or “machine start code for P2S was changed” in a consistent place (not just when the update is pushed) they can self-diagnose expected behavior changes and file much more precise bug reports when something actually breaks.
For users who modify their machine start gcode for any reason, this would help them stay up to date and port their changes to the most up-to-date versions.