I learned of the new update when I received a report of cursor 0.42.4 not installing. When I investigated, I discovered it was gone and replaced with a new update from today.
Please don’t be so quick to delete old versions. Now people using Cursor on NixOS will be stuck without any options until we get the PR approved and through the build system. (This often takes a week or two.)
Hey, we’ll try to consider it, but if you need the previous version, you can request it from us
That assumes a person is installing it by hand each time.
NixOS is one of the up and coming “immutable” distros that put all the binaries in a separate locked-down area. It’s a favorite of the financial industry due to its immutable binaries and the ability to ensure only vetted package versions are in use.
When installing an AppImage (or other binary bundle), everything needs to be patched to point to the right paths, specify dependencies, etc. This is done automatically by a script (“derivation”) that lists the download path, validation hash, dependencies, etc. If the download is gone, that package cannot install.
So far, I’ve maintained the cursor derivation for the “unstable” branch. We also have stable releases twice a year (with security updates). I was hoping to get your editor into the stable distribution, but if the downloads are ephemeral I can’t do that. (Stable gets a longer test period and new releases need to be demonstrably stable before being ported into it.)
P.S. Since NixOS places the code in a sealed, immutable file, cursor’s automatic update won’t work.
While I fully understand the Nix OS thing (I use nix right now for a reproducible dev env), I want to say that keeping old versions available means keeping old APIs available and fully working.
I might bet Cursor team and Cursor as a product is in a rapid development phase, where slowing down the development by maintenance burden is not what we all want.
I was in a situation where I needed old Cursor version desperately because of some unpublished feature which I accidentally found, but which was not working in the latest auto-updated Cursor. That feature was a backbone of my dev process (and still is, when was fixed in some minor release later in 2 weeks).
I am on both sides of this issue, and I still prefer rapid growth.
Rapid development and a release process aren’t incompatible. Nor does it have to be a maintenance burden. It’s readily solved with keeping a prior release or two along with actually notifying us all about updates. If there’s a breaking change coming, you let people know of the time window in which they need to upgrade.
These are basic requirements for any commercial product.
You gave a perfect example why the current behavior causes pain — 1) you use nix for a reproducible dev env (which depends on packages having a back catalog of releases) and 2) a sudden Cursor update broke your working environment. Letting you update by your own choice, and having a rollback version or two would eliminate this roadblock.