0.44.x has been a great upgrade over 0.43, thank you for the extra work you’ve put in over the past few weeks before 2025.
I really enjoy reading your changelog’s, but noticed that sometimes when there’s an update (like the 0.44.9) … there’s no update to the changelog. Can you put something into the changelogs with each update you push? Even the smallest changes are interesting to read about.
I find myself rushing here to see whats changed only to end up searching the forums for the version number and finding this post instead of a change log .
Every time I get a little popup on the bottom left corner of my screen I get excited. I rush to the change log, to find out there is no description whatsoever. Im in the same boat of wanting to see a little update.
A detailed changelog with each update would be really helpful. Feels a bit like Russian roulette clicking that upgrade button on a day when I have a lot to accomplish.
@deanrie can you pass this thread on to the Cursor devs? 0.44.11 was released and there was no update on the change log as to what’s changed. In the dark on what changed between 0.44.9, 0.44.10 and now 0.44.11.
The changelog is really unclear.
UPDATE (0.44.1-0.44.11): Fixes and improvements to dev containers, chat codeblocks on windows, and the agent. Decreases Cursor Tab Latency on Remote SSH. Fixes bug that prematurely triggered the free trial ended popup. Better observability for errors and crashes.
We release updates using a gradual rollout so, by default, not everyone gets the update at the same time. This length of the rollout depends on how big the update is in terms of changes to the app but usually is 2-3 days for most rollouts.
We usually add release notes to our changelog once the rollout has made it to a certain portion of our users - we do this so that if there is a bug early on, we can catch it and fix it before the release notes are out for a broken update!
Additionally, as features change and evolve, even within minor releases of Cursor, we therefore choose to keep the changelog simple, but still tell you what has changed! For major changes to features, we try to keep the docs up to date to teach you how things work, instead of trying to add mini tutorials into the changelog itself!
Hope this makes sense, but if you have any specific feedback about where something has not been mentioned or explained in the changelog, do let me know!
Thanks @danperks , if the release notes start including the patches, that’d be awesome. I had a team member today as what’s changed between 0.44.9 and 0.44.11 and I couldn’t answer them.
Hey, usually these changes would just fall under bug fixes and stability improvements, and for most users, there is likely no visible changes in the editor, except if for users facing bugs or issues we may have fixed!
@danperks I’m finding the opposite unfortunately - just upgraded to 0.44.11 and feels like multiple regressions but it’s more difficult to file helpful bug reports when I’m completely in the dark about what changed when. I think it would be much better if you were just fully transparent about the changes. If there’s a broken update then you can just update the changelog too. No one expects every single point release to be perfect so there’d be no shame in that.
I’m definitely not arguing against the value of a high-level changelog which is short and simple - that is of course important to have. I’m just saying that some of us need more control over and understanding of changes to our IDE, and the current changelog prevents that. For example @devgrinder made the great point that we shouldn’t have to play russian roulette every update. Additionally it’s quite misleading for the popup to offer a “what’s new” link which leads to a page which gives zero information about what’s new (since I’ve already done multiple updates within 0.44.x).
Several of us are asking for this, so I hope you can take that as a sign that it’s worth reconsidering the current approach. Thanks!
I’d be interested to know what regressions you have found in upgrading to 0.44.11, as I can’t say I am aware of anything major that has gotten worse in 0.44.11.
I agree that visibility is not a bad thing here, so I’ll feed this back to the team to see what we can change to improve things in the future.
This gives the user a clear message about the specific changes that will be installed on the next update, with the option to skip it for now or ignore it completely.
The changelog is linked from Cursor’s update notification, but:
it’s hard to tell which version I’m on
it’s therefore impossible to tell which features I might be getting in addition to what I already have now
the changelog I’m seeing is always the same (unless you remember what specific minor entries were listed at the bottom)
Now, granted, updating is not a huge problem, but it requires me to close all windows and terminals, scratch files etc., so I’d rather not do it for some minor bugfix, but I definitely want to know when I’m getting a major new release.
Splitting the changelog into a detailed list of actual changes and a general “What’s new” overview would make sense. Grafana did just that, for example. They have a What’s New page and a detailed changelog with everything that didn’t make it onto that page.
Sparkle is nice, but I doubt they will use it because it’s macOS specific and Cursor IDE is a cross platform app.
That said, the community has been asking for awhile to produce better changelogs. I don’t mind clicking the read the changelog link when cursor prompts to update, in fact I do it every time… what I’d like though (like many others) is better release notes.
Cursor team, please stop grouping the patch updates with the minor versions. Take inspiration from the default behaviour on Github releases and publish a separate entry for each update.
Assume we are interested in the minor things and provide more context. It’s a bit more work for you but you’ll have a lot of happy community members for doing it.
It’d also potentially help with triaging issues if engineers know what’s changed we may be able to communicate better to you when there’s an issue.