The current changelog formatting is way too terse. Is there any way Cursor team could commit to being more transparent when rolling out updates to users?
I understand you guys are a startup and likely focused on shipping fast and iterating as fast as possible, but it’s important to understand that A/B testing should be handled better than forcing users into things without recourse or ability to roll back. The worst part is that, there is no transparency around feature set changes for us to review when things get updated.
Why not just post the real commit messages instead of something that’s been heavily filtered by product? We’re all developers and I’m certain we can grok what things did what.
A breakdown like the following would be useful:
- Breaking Changes:
- Change 1
- Change 2
- Major Features:
- Added:
- Feature y added to replace x, it does this
- Removed:
- Feature removed for x, replaced by y
- Feature removed as it was not being used
- Added:
- Minor Features:
- Added:
- Feature x that improves this
- Changed:
- Move feature x to a, b to improve UX
- Added:
- Major Fixes:
- Fix 1
- Fix 2
- Minor Fixes:
- Fix B
- Fix A
Recommendations to improve user experience:
- A preview branch that has rolling changes and a psuedo-stable branch that people can revert to and has vetted changes that have been tested by users trickled in
- More transparency around breaking changes or features being removed
- Better changelogs in general, as right now they’re extremely terse and ambiguous
Literally just those 3 things would make your forums not up in arms when you remove half the feature set and move everything around without letting anyone know or documenting it anywhere.