Atom really needs the ability to have soft updating. If I am going to rely on it for my business and program with it on a daily basis I need to trust the update functionality isn’t going to break my extensions, or if it is I will be able to wait on the upgrade.
Atom (at least on windows) stores all previous versions, so you if you installed for example 0.192 and it got updated twice (0.193 and 0.194) you’ll find versions 192 193 and 194 in your $HOME/AppData/Local/atom
Squirrel actually only stores the last Atom version you were using, not all of them (and in
%PROGRAMDATA%/atom, depending on whether installing to
Atom is still alpha, prerelease, etc. They’re still moving fast and breaking stuff, it’s only settling down for stuff that is pretty much in 1.0-state already. I think you can expect it to be much more stable after the 1.0 release, but anything that slows down the churn right now would be counter productive.
In addition to @braver’s quite accurate comments, you could “pre-break” things by running Atom in 1.0 API compatibility mode, by launching it using
atom --one. This will instruct Atom to not play nice with packages that haven’t updated for the 1.0 API and let them crash. This way, you can be more certain that the packages that survive in 1.0 API compatibility mode will continue to work at least through v1.0.
Yeah totally cool. Keep up the churn. I am just saying a super important feature is a no complaints super simple way to roll back update changes, or a way to do a soft run to see if extensions will output errors. That way I can decide what to do. I mean the user should be prompted that this update with produce errors in blah blah extension pretty easily right? I noticed they are all logged. Sorry I have only used it and not looked at the code so I can only speak from a users perspective.