Hey Team,
First off, fantastic job on all these updates, thanks for cookin’! The rapid pace of new features and improvements really shows your commitment to making Cursor better with every release. I wanted to share some feedback regarding the changelogs.
I would think the model would be … you get dates for semantic readers but you get versions for details… vs code does a good job imo.
GitHub excels at developer-friendly changelogs by combining clarity with technical depth, using semantic versioning to organize updates into clear categories
However! They do dates and not versions. Since there is not anything to download and install or opt in/out they can get away with this. Cursor… should not. Better put, it should not fall in the upgrade inoptionality that web affords on its users.
Another key aspect is that cursor rolls updates to users so the date isn’t actually the date for all people. If I open the app after 2 months and wonder what’s changed I’m looking by version number and not by date. How can I remember the date I last updated 2 months ago, was it 2 days before then or also 2 months.
I’d love to see:
- Maintain separate entries for each version, even minor ones
- Include bullet points detailing what changed and why
- Reference any security advisories or CVEs specific to the version so we know our security posture/exposure while running that version
- Group related changes together while maintaining version specificity sure roll the date in there if you want.
As an example, update blending and lack of specificity in 0.42.1 - 0.42.5 is a good example of why it’s important to keep things isolated. If I was running 0.42.3 in the middle do I have a problem or do I not? and with which CVE…
Again, really appreciate the hard work and dedication from the entire team. These updates are moving Cursor in a great direction, and with clearer, version-specific changelogs, it’ll be even easier for all development teams to track and stay current.
Keep cookin!